--- Log for 20.10.104 Server: burroughs.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 15 days and 23 hours ago 00.00.50 Join [IDC]Dragon [0] (~idc-drago@pD9FF8E99.dip.t-dialin.net) 00.01.18 # hi 00.01.28 # <[IDC]Dragon> 'evening 00.02.25 # <[IDC]Dragon> I'm just in for a quick visit 00.03.54 # hey 00.03.55 # Interesting discussions today in the channel... 00.04.11 # <[IDC]Dragon> the database? 00.04.18 # the iriver isn't very good at shuffling songs in playlists 00.05.16 # [IDC]Dragon: Yes. I wonder why all those various additional tables per relation are proposed 00.06.00 # This will soon get us in a table mess, imho, especially if more different info is added. 00.06.04 # <[IDC]Dragon> I've never been good at databases (my weak point) 00.06.45 # Sequential search is slow, of course, but why not use a binary tree for search? 00.06.55 # <[IDC]Dragon> so I stay away from that discussion 00.08.49 # I'm not very good in that area either (and I don't see the benefit from a db in the proposed form - static on the box) 00.10.00 # <[IDC]Dragon> all I remember is that there is a redundancy/speed tradeoff in the # of tables used 00.19.43 Quit iRiverMan ("CGI:IRC (Ping timeout)") 00.20.09 # [IDC]Dragon: Argh! Solitaire accesses an array with out-of-bounds index! 00.21.11 # <[IDC]Dragon> yours, or before? 00.21.26 # Before. 00.22.05 # Try the following: Start solitaire. From the menu, select "Help", Note down the string displayed in the first line. 00.22.22 # <[IDC]Dragon> sorry, not now 00.22.31 # Start the game, and immediately exit to menu. Select "Help" again. What do you see? 00.24.32 # yyyss a key to see 00.24.40 # y with the dotty things :) 00.24.43 # Yup. 00.26.36 # The mistake itself seems obvious, but I don't know whether fixing it will break the proper behaviour of the game... have to try 00.31.42 # why would it break the behavior of the game? 00.31.54 # well, i'm not too sure of the fix anyways without looking at the source 00.32.22 # the 'press a key, get the info' kind of help is nice, but if you do try to fix the bug you should also make the text disappear instead of just sitting there 00.32.38 # ie.. on keypress, clear the screen, draw the help text and then draw the corresponding button text 00.34.20 # The problem is that as soon as the game starts, the first 3 bytes of the help text get overwritten. There is an array immediately before it, char stacks[4]. The init writes from 0 to 6... 00.34.56 # switch it to char stats[6] or 7 then? 00.35.32 # No, it looks like only the init is wrong. It should write form 0 to 3 iiuc 00.39.08 # oh 00.40.24 # Hmm. 00.43.07 Quit silencer_ (Remote closed the connection) 00.43.09 Join silencer [0] (~silencer@zen.via.ecp.fr) 00.51.25 # <[IDC]Dragon> Phew, I'm done with the radio. 00.52.07 # What solution do you have for the presets? 00.58.37 # <[IDC]Dragon> long press of Right 00.58.56 # <[IDC]Dragon> and extra menu entries beforehand 00.59.10 # <[IDC]Dragon> for what can't be on buttons 00.59.20 # <[IDC]Dragon> gotta leave now 00.59.32 Quit [IDC]Dragon () 00.59.35 *** Saving seen data "./dancer.seen" 01.36.26 Join napgravy [0] (user@S0106004095d1df8f.cg.shawcable.net) 01.39.31 Quit napgravy (Client Quit) 01.52.54 Quit mecraw_ ("Trillian (http://www.ceruleanstudios.com)") 02.03.03 Join edooo [0] (~edooo_188@82.129.244.5) 02.05.47 Quit edooo (Read error: 54 (Connection reset by peer)) 02.05.58 Quit AciD (Remote closed the connection) 02.13.33 Join Bluechip [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 02.16.54 # hi bc 02.26.45 # hi 02.33.40 Part amiconn 02.36.03 Join zargoyle [0] (zazz@079-099.dialup.sunysb.edu) 02.39.27 Quit Sebulba02 (Read error: 54 (Connection reset by peer)) 02.41.16 Quit midk_ (Read error: 104 (Connection reset by peer)) 02.42.59 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 02.54.21 Quit edx (Read error: 110 (Connection timed out)) 02.59.37 *** Saving seen data "./dancer.seen" 03.38.37 Quit midk (Remote closed the connection) 03.42.20 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 03.44.01 Part Bluechip 03.53.05 Quit zargoyle ("sudden death") 04.19.43 Join Sebulba02 [0] (~Sebulba02@Darth-Sebulba04.active.supporter.pdpc) 04.33.52 Join edx [0] (edx@pD9EAA501.dip.t-dialin.net) 04.49.44 Quit midk ("Leaving") 04.50.47 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 04.59.40 *** Saving seen data "./dancer.seen" 05.02.24 Join adiamas [0] (~chatzilla@host-64-179-64-18.alb.choiceone.net) 05.14.04 Quit scott666 ("i'll be back...eventually...") 05.19.14 Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) 05.46.36 Quit scott666 (Read error: 104 (Connection reset by peer)) 05.52.03 Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) 06.59.41 *** Saving seen data "./dancer.seen" 07.04.54 Quit scott666 ("i'll be back...eventually...") 07.12.56 Join LinusN [0] (~linus@labb.contactor.se) 07.22.56 Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) 07.24.39 Quit adiamas ("Chatzilla 0.9.65 [Mozilla rv:1.7.3/20040913]") 07.49.56 Quit matsl (Remote closed the connection) 07.52.29 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 08.18.47 Join MofuTech [0] (~80ebf233@labb.contactor.se) 08.19.11 # hello 08.19.47 # have you guys gotten that broken h120 you needed? 08.20.04 # i think i know someone who broke his... 08.20.40 # i'll ask him if he wants to give it to me, or if i should buy it from him... 08.21.39 Join Lurkski [0] (~Miranda@24.30.163.142) 08.22.56 # MofuTech: we have a broken one already, so we don't really need another one 08.23.06 # thanks anyway 08.23.42 # LinusN, drop yours? ;) 08.25.51 # hehe 08.26.08 # no, we got a broken 120 on Ebay a while ago 08.26.39 # oh, where zagor101 swiped it at the last second? 08.26.44 # yes 08.26.52 # oh ok 08.27.14 # what's that called? 08.27.16 # how is the development process? 08.27.17 # camping? 08.27.22 # and i have a 140 PCB on it's way here as well 08.27.31 # and a broken remote 08.27.45 # well, the threading works 08.28.04 # i have written most of the interrupt handling code 08.28.14 # working on the tick timer interrupt 08.29.46 # how did you guys decide on starting work on the h-series? 08.31.00 # lots of pressure from misticriver and iriverlounge 08.31.08 # :-) 08.31.21 # we have been looking for possible target platforms for a while 08.32.00 # were your options only limited to UMS devices? 08.32.06 # and the iriver is a good candidate, since it is built out of off-the-shelf chips, with publicly available documentation 08.32.15 # UMS? 08.32.23 # USB mass storage class 08.32.31 # not at all 08.32.46 # but we prefer it 08.33.15 # its good that the info on the iriver chips are available 08.33.32 # absolutely 08.34.03 # there has been a lot of work concerning libnjb and the nomad jukebox/zen/dell players 08.34.16 # oh 08.34.19 # have you ever considered those devices? 08.34.33 # not that i know of 08.34.58 # i don't know what hardware they are based upon 08.35.10 # ipod is out of the question 08.35.16 # so is rio karma 08.35.29 # why is that? 08.35.40 # they are based on the PortalPlayer chipset 08.35.58 # you have to give away your firstborn to get the data sheets 08.37.06 # wow 08.38.14 # i think that the iaudio m3 is based on the same hardware as the h100 series 08.38.41 # im not too sure though 08.40.23 Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) 08.42.09 # if everything goes to plan, God willing, what will the first few releases of the firmware look like? 08.42.29 # they will look like rockbox on the archos 08.42.52 # they will probably play wav and mp3 08.43.04 # no recording 08.43.52 # sounds good 08.44.13 # for a start, it has to work first 08.46.54 Join millow [0] (~millow@67.227.adsl.i4surf.net) 08.50.26 Part millow 08.50.50 Join millow [0] (~millow@67.227.adsl.i4surf.net) 08.53.45 Part millow 08.54.00 Join millow [0] (~millow@67.227.adsl.i4surf.net) 08.56.48 Join Dujodu [0] (APDesign@CPE-24-167-199-72.wi.rr.com) 08.57.22 Join [IDC]Dragon [0] (~idc-drago@pD9E34C4A.dip.t-dialin.net) 08.58.00 # <[IDC]Dragon> LinusN: I made a mess in radio.c 08.58.20 # <[IDC]Dragon> #ifdef hell 08.58.42 Quit millow (Client Quit) 08.59.45 *** Saving seen data "./dancer.seen" 09.01.24 Quit [IDC]Dragon () 09.01.37 Join Zagor [242] (~bjst@labb.contactor.se) 09.02.15 Quit MofuTech ("CGI:IRC (EOF)") 09.09.13 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 09.10.37 Join kurzhaarrocker [0] (~knoppix@p50876588.dip0.t-ipconnect.de) 09.16.38 # i'm beginning to have second thoughts about the shine codec. it purposefully degrades quality to enhance performance. will we ever be happy with such an approach? 09.17.33 # Are there alternatives that don't delay the development process? 09.18.44 # well I'd say we simply start with recording to wav 09.19.17 # cool, we start with recording and not with playback :) 09.19.42 # ah, no. shine is only for recording. for playback we use libmad, which has no problems. 09.20.01 # in fact libmad has higher quality than many floating-point implementations 09.20.12 # * Dujodu wishes he knew what you were talking about. 09.20.20 # Ah, I see. 09.21.03 # Dujodu: its about the software engine that encodes the sound to mp3 format. That's necessary on targets like iriver that don't have a dedicated chip for that. 09.21.27 # that's cool 09.22.25 # and pretty amazing, that you guys are making it. 09.22.48 # I don't. Zagor does. 09.22.56 # heh 09.23.15 # you probably do some other cool stuff though 09.23.16 # Zagor: shine is a bare-bones mp3 encoder 09.23.42 # and no, we will not be happy with the quality, we will have to enhance it ourselves 09.23.51 Quit kurzhaarrocker ("Trillian (http://www.ceruleanstudios.com)") 09.24.18 # ...which will be a HUGE work. we need to invent a whole psychoacoustic model. 09.24.30 # probably 09.24.51 # it would of course be nice if we found another, better encoder 09.24.51 # Psycho acoustics \o/ 09.25.17 Join kurzhaarrocker [0] (~none@p50876588.dip0.t-ipconnect.de) 09.25.25 # realtime encoders don't grow on trees, unfortunately 09.25.49 # well the question i'm asking is: do many people really prefer to record direct to mp3 rather than to wav and then use a high-quality offline encoder? 09.26.04 # WAV recording, "until something better pops up"? 09.26.05 # it's a matter of disk space 09.26.25 # is it, really? 09.26.26 # And a matter of battery drain. Wav takes considerably more hd activity. 09.26.29 # a 2-hour lecture in WAV takes a few Kbytes :-) 09.26.35 # :-) 09.26.55 # kurzhaarrocker: mp3 takes considerably more cpu power... :) 09.27.09 # LinusN: Recording speech doesn't require 44.1khz stereo :) 09.27.14 Quit silencer (Nick collision from services.) 09.27.15 Join silencer [0] (~silencer@zen.via.ecp.fr) 09.27.32 # Well I suspect that cpu power is cheaper than spinning hd motors and heads. 09.27.38 # indeed 09.28.04 # but i don't think those 1.8" drives are that power hungry 09.28.07 Quit silencer (Nick collision from services.) 09.28.57 # If we can get a device that ergonomically and reliably can record > 5h to wav on batteries I'll buy it and don't need any mp3 encoding any more. 09.29.24 # kurzhaarrocker: what are you recording for >5h? 09.30.10 # * Bagder spots something weird on the web site 09.30.20 # I use it to track live concerts. Its a plus to record the entire concert which may feature 6 bands and last from afternoon till midnight. 09.30.42 # Zagor: is the lower part of the menu supposed to be left aligned and the upper part right aligned? 09.30.42 # kurzhaarrocker: you record 5-hour concerts in the audience? 09.30.53 # Bagder: no, that's a wiki bug. me fix. 09.31.00 # Bagder: the wiki css seems bad 09.31.06 # No, I fix the mic somewhere, put the stuff somewhere else and rock the stage myself :) 09.31.17 # LinusN: that's html, not css actually 09.31.58 # Zagor: the point is probably valid for students that record lectures etc 09.32.11 # ok 09.32.15 Join silencer [0] (~silencer@zen.via.ecp.fr) 09.32.21 # fixed 09.32.23 Nick silencer is now known as silencer_ (~silencer@zen.via.ecp.fr) 09.32.30 # nice 09.33.14 # Zagor: you could only beat LinusN's 11-Minute fix because bagder didn't write a bug report. 09.33.23 # Bagder: actually it appears to be an issue with fcpp. see Makefile for head.tmpl 09.33.33 # aha 09.34.59 # hey! an Ondio q on the forum! ;-) 09.36.12 # * Bagder walks off to get a cup of that black stuff 09.36.51 # hardcore smokers drink the tar? 09.39.48 # ha 09.42.51 # ot: Do any of you use fancy gui cvs clients? Or do you cvs all in the shell? 09.43.34 # shell all the way 09.43.55 # emacs is my gui 09.44.07 # if you're on windows, i can recommend tortoisecvs though. it's the best cvs gui i've seen. 09.44.24 # * kurzhaarrocker considers emacs more as a shell than a gui 09.45.08 # tortoisecvs is cool. 09.46.23 # I just wished I found out how to modify the diff parameters to create patches with it. 09.46.32 # with tortoisecvs 09.48.11 # try the "Make patch" menu item :) 09.49.33 # yes but with that I don't know how to specify the diff -B option. I get many many honks that are only changes because of whitespace. 09.50.05 # sorry, it's the -b option of course. 09.50.31 # right. I've never actually tried making patches with a gui tool. 09.50.53 # I always used the command line tool for that, even when using tortoise 09.53.41 Part Lurkski 09.58.59 # strange: cvs diff doesn't seem to be allowed as anonymous. But if that was true how can turtoise manage that? 09.59.19 # diff should be allowed 09.59.31 # what error do you get? 10.01.13 # : no such repository 10.01.13 # cvs diff: authorization failed: server rockbox.haxx.se rejected access to /cvsro 10.01.13 # for user anonymous 10.01.13 DBUG Enqueued KICK kurzhaarrocker 10.01.13 # cvs diff: used empty password; try "cvs login" with a real password 10.01.53 # you need to login for anonymous access too, just use username "anonymous" and no password 10.02.20 # http://www.rockbox.org/twiki/bin/view/Main/UsingCVS :) 10.03.23 # just tried anonymous diff here, works fine 10.03.53 # Ok I generally seem to be a cvs moron. 10.06.46 # I thought once you have checke something out you didn't have to specify the -d option in cvs any more - as long as you are within your cvshome. 10.08.35 # you don't 10.11.00 # When I don't specify the -d with cvs login it correctly says (Logging in to anonymous@rockbox.haxx.se) but then there's the authorization failure again. 10.11.16 # with -d it works 10.11.48 # you need to run two commands: first login, then checkout. both need -d. after that, you don't need -d. 10.12.30 # I still seem to need it afterwards. 10.12.43 # then something is wrong in your sandbox 10.13.09 # try checking out to another directory 10.15.01 Join amiconn [0] (~jens@pD9E7EF9B.dip.t-dialin.net) 10.15.16 # Morning 10.16.25 # morning 10.17.30 # moin 10.19.30 # I have a problem with the solitaire plugin... it is hard to adapt to Ondio. Not because of the number of keys, but because it uses a clever macro for the help text display. 10.20.05 # I didn't find a way to include conditional compilation *within* a macro. Is that at all possible? 10.20.13 # no 10.20.16 # not portably 10.20.24 # ouch, u-g-l-y! 10.20.35 # make two macros 10.20.41 # Hmm. So that means I have to unroll all uses of that macro 10.20.57 # yes, please. it's a single function call 10.21.12 Join Lynx_ [0] (lynx@134.95.189.59) 10.21.17 # I don't believe it! Tortoise cvs created a CVS/Root file that has CR+LF endings. command line cvs doesn't like that, it wants LF only. 10.21.45 # haha 10.21.46 # Zagor: I would be no more a single call on Ondio, depending whether the button has 2 functions or not. 10.21.48 # kurzhaarrocker: that's what you get for fooling with guis ;) 10.21.50 # wwwwiiiinnndddooowss ;-) 10.22.10 # amiconn: aha. well all the more important to not make the code harder to read then 10.22.14 # kurzhaarrocker: I use command line cvs only (never looked at tortoise) within cygwin 10.22.42 # Zagor: Okay. Then I'll go for unrolling the macro completely. 10.23.03 # good 10.23.16 # Here at work we _must_ use the cvs from Eclipse. Don't ask my opinion on cvs client that don't cvs! 10.25.34 # rigid tool rules are always good for productivity. i bet you're only allowed to use a company-specified text editor too? 10.25.45 # and pants 10.27.40 # The pants are up to my choice. But whenever we decided to use _that_ tool only we very soon got stuck in the restrictions that tool has and made a hell of effort to circumvent them. I prefer to rigidly specify the results and not the tools. 10.30.00 # classic clueless management. they have no idea how to manage the development process, so they manage whatever they can understand: the names of the tools 10.30.42 # i see it everywhere 10.30.55 # erm, its a very small company. Fortunately those who make the decissions suffer them too. :) 10.31.22 # hehe 10.47.33 Quit Dujodu () 10.52.25 # Zagor: Is it okay to continue with plugin adaption (both for Ondio and for USB handling via default handler) while the feature freeze is in effect? I would like to change the plugin api when done with tha (taking out usb_screen(), therefore breaking backwards compatibility -> sort functions) 10.53.56 # if you are reasonably confident no problems will remain after the weekend, I think it's ok to continue 10.57.24 # A design question: I believe that triggered recording _could_ be split into very little code that must reside within rockbox, and other code (most of it) that could be separated into a plugin. Would it be desirable to allow triggered recording from a plugin only? 10.58.46 # kurzhaarrocker: *Imho* recording is a core feature, and core features should be handled in the core. 10.59.14 # i agree 10.59.18 # It would be slightly hazardous though as then I'd need a callback so that rockbox can pass events to the plugin 10.59.49 *** Saving seen data "./dancer.seen" 11.02.46 # Zagor: I'd rather do that plugin stuff before release, because (iirc) shortly after the last release we broke api compatibility. That raised a number of "support calls" on the ml, because people wanted to flash with mixed rockbox/plugin versions, and got "incompatible version" 11.03.57 Join B4gder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 11.04.19 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 11.04.19 # * B4gder tries chatzilla 11.04.47 # amiconn: yes, i agree 11.08.04 Join pillo [0] (~trillian@adsl-ull-93-252.46-151.net24.it) 11.09.36 # (wished I had a reason that strong for including triggered recording) 11.09.43 # Bagder: binary db format table added 11.10.20 Quit kurzhaarrocker (Read error: 104 (Connection reset by peer)) 11.10.30 # we should probably have a db version field too 11.11.08 # version field is goodness 11.15.31 # I'll try to adjust my perl script for this format during Agnes' afternoon nap 11.15.41 # great 11.17.12 Join ashridah [0] (ashridah@220-253-119-223.VIC.netspace.net.au) 11.20.43 Join kurzhaarrocker [0] (~none@p50876588.dip0.t-ipconnect.de) 11.22.03 Join Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 11.22.13 # Zagor, Bagder: Instead of adding all that mapping tables, wouldn't it be faster to just add indices that allow a binary-tree search? 11.22.32 # that's what we do 11.22.43 # Imho having all those mapping tables would bring us into a table mess 11.22.52 Quit B4gder ("ChatZilla 0.9.61 [Mozilla rv:1.7.3/20040910]") 11.22.54 # which mapping tables? 11.23.19 # I read yesterday's discussion... 11.23.43 # check our zagor's updated wiki instead 11.23.47 # check out 11.23.50 # * amiconn checks 11.26.55 Nick Zagor is now known as Zagor|lunch (~bjst@labb.contactor.se) 11.28.16 # Hmm. I see a problem with "array of pointers to songs" How many entries should that array have? 11.31.30 # I don't understand why we need different tables at all. All song info of one mp3 file is connected anyway, so imho it might be easier to use just one table, indexed on song name, artist, and album. It would be easy to add more criteria this way (year...) 11.34.45 # <- knows nothing about dbs. Would the indices be separate data structures? 11.36.02 Quit pillo (Read error: 104 (Connection reset by peer)) 11.36.57 # Yes. The index would contain the field the db table is indexed on, and a pointer into the table. 11.38.21 # One index should fit completely into memory, but tthat should not be a problem. Assuming a field length of 50 chars (more than id3v1 provides), it would allow ~30,000 db entries (tracks) on the Archos (~1.5 MB) 11.38.31 # Would all indices (eg index for artist, year, album...) go into the same table like data structure? Or would they be stand alone and independend? 11.39.49 # Separate files would make updates easier, while all in one file might be better for assuring db consistency 11.42.07 # Hmm, for combining the results of several indices, they either have to fit together, or we would have to use an intermediate file... 11.53.09 # ..or don't load the complete index to ram 12.01.41 Quit Bagder_ ("Leaving") 12.10.04 Join Lynx [0] (lynx@134.95.189.59) 12.15.55 Join Lynx0 [0] (lynx@134.95.189.59) 12.23.35 Quit Lynx (Read error: 60 (Operation timed out)) 12.24.06 Nick Zagor|lunch is now known as Zagor (~bjst@labb.contactor.se) 12.24.18 # amiconn: i think we are discussing different use cases. 12.24.58 # I don't think so 12.25.31 # ok, then I don't understand how you mean. how do you find all songs that are in a specific album 12.26.10 # You mean, from browsing the album list? 12.26.24 # yes, the list of albums made by a specific artist 12.26.42 Quit Lynx_ (Read error: 110 (Connection timed out)) 12.26.42 Nick Lynx0 is now known as Lynx_ (lynx@134.95.189.59) 12.27.20 # : Album list is displayed, so the album title is known. Load the album index, search for that album (binary tree search), and you'll find all songs of that album 12.28.20 # there will be more than one albums called the same thing made by different artists 12.28.46 # also, how is a search faster than a lookup? 12.30.25 # It's certainly not faster, but should be reasonably fast. My point is that a lookup is only possible if you use a predefined table for that relation. 12.31.03 # of course. why is that bad? 12.31.17 # Imagine how many tables that would be if you extend the concept to include artist, album, song name, year, genre, play time..., and the want to allow any combination of 2 (or 3...) criteria 12.31.48 # imagine how many searches you get if you *don't* have any tables 12.32.08 # we can't solve everything with lookup tables, but we can make the common cases much simpler and faster 12.32.51 # I still think searching would be relatively fast if we utilize binary search. 12.32.51 # it is an explicit design goal to "waste" database size if we can gain cpu time and memory use 12.33.15 # you still haven't explained why we should be "reasonably fast" when we can be immediate 12.33.27 # Many lookup tables also increase db size, which slows down seeking 12.34.12 # seeking is always orders of magnitudes faster than searching 12.34.25 # Lookup tables are not immediate either, because of the hd accesses. CPU time would be only a small fraction of that. 12.34.50 # you are avoiding the question. searching uses many more hd accesses than lookup. 12.35.20 # Not with the index in-mem approach. 12.36.01 # ?? how do you search an index. you need to look at the data the index indices 12.36.28 # and in any case, album name (for example) is not a unique data key 12.36.49 # Yes, but only on those that match. This has to be done with lookup as well 12.37.04 # I never said the key has to be unique 12.37.15 # arghh! lookup does not search, it reads the right data entry immediately 12.37.40 # You mean, each table contains all data from a song??? 12.38.08 # you've seen the table format suggestion 12.39.33 # can we get back to the issue? why do you want to use search instead of lookup? 12.39.34 # Yes, and there it has pointers to the rest of the song data. That means you have to load it separately -> additional hd accesses 12.39.58 # yes, a single access. searching requires dozens. 12.41.11 # No it doesn't. You load the index, search that, and find a number of mathing pointers. Then you load that data, which is (obviously) exactly the same number of entries than lookup would yield 12.41.19 Quit Lynx_ (Read error: 104 (Connection reset by peer)) 12.41.28 # you can't search the index, you need to look at each data point: load it from disk 12.41.43 Join Lynx_ [0] (lynx@134.95.189.59) 12.41.53 # That's the purpose of the index - searching 12.42.25 # you can't binary search an index. you have to look at the data to know which way to search next. 12.43.08 # The index contains both the index key value and the pointer, so no additional data lookup required 12.43.30 # right, that is exactly what my proposal contains 12.45.47 # Not exactly. You store album, artist, and song name separately. This requires index arrays in each of the additional tables, which raises the question of how large those arrays should be 12.46.25 # the array size is specified in the header. it is big enough to suit the data set. 12.47.20 # What if this is e.g. set to 20 tracks per album, and then an 21-track album is added? This requires re-generating the whol edb 12.47.44 # the database is always regenerated 12.48.06 # a nightmare for the jukebox but a piece of cake for a pc 12.48.07 # Yes, but it should be possible on the target 12.48.17 # it is possible, just a lot of work 12.48.35 # (lunch) 12.48.48 # the format is designed for easy reading, not easy writing. 12.50.26 Join Lynx [0] (lynx@134.95.189.59) 12.59.53 *** Saving seen data "./dancer.seen" 13.04.54 # i wonder why people are so focused on generating the database ono the jukebox itself? 13.05.24 # beats me. store the perl script and perl.exe on the jukebox instead. 13.05.44 Quit Lynx_ (Read error: 110 (Connection timed out)) 13.05.44 Nick Lynx is now known as Lynx_ (lynx@134.95.189.59) 13.05.54 # perl.rock :-) 13.05.58 # haha 13.06.05 # It's only interesting for freaks like me who actually record with the recorder. And - well - for searching only I don't care about databases at all. I want statistics and ratings. 13.07.06 # i want it too, but I don't think we should mix it with the id3 database. the statistics are long-life data that you want to make sure survives a long time. the id3 database can be recreated at any point in time. 13.08.50 # that's true. And if we did as dirty things as store that statistical info in some id3 tags too even that data could be recreated. 13.09.02 # yes 13.14.33 # But now I think you're right: it might be good to think about the statistical infos and updating / reindexing them separately. Even if we had to update an id3 tag and half a dozen db entries - for that task we have plenty of time. 13.17.08 # Zagor: Your db design may lead to very large index tables, if (for instance) you have many tracks by one artist, even if the number of tracks by other artists is much smaller. 13.17.27 # yes. we waste disk if that gains cpu or ram 13.18.20 # * kurzhaarrocker wastes time to gain some food now 13.18.27 Part kurzhaarrocker 13.19.00 # Searching such a large index might take significantly longer thatn searching an index into a one-entry-per-song table. I happen to have that case on my disk - I have > 100 songs by one group 13.19.50 # no it won't. seeking a file will always be MUCH faster than searching it. 13.19.55 # LinusN: Generating the db on the box itself might be useful if you connect the jukebox to a computer that is not yours and add songs. 13.20.17 # amiconn: store the index program on the jukebox. then it doesn't matter what computer you connect to. 13.20.57 # Zagor: It does matter, or I'd have to store the index program for any CPU and OS type I might come across 13.22.01 # Zagor: You'd have to search the index with either approach. The only search to avoid with indexing is searching the ram table data 13.22.04 # come on, be real. how many operating systems do you connect to normally? 13.22.13 # 3 13.22.29 # windows, linux and another unix? 13.22.38 # how about mac with os9 : 13.22.41 # Windows, Linux, and AmigaOS 13.22.57 # fine, then you need perl.exe, perl-amiga and update.pl 13.23.01 # s/ram table data/raw table data/ 13.23.10 # and you are unable to connect it to the linux box for indexing? 13.23.13 # amiconn: no you don't need to search with a lookup table 13.24.03 # Zagor and amiconn, i think you're so far apart that you need to explain your concepts from the bottom up 13.24.14 # my concept is in the wiki :) 13.24.18 # (lunch) 13.24.27 # but i agree, it seems we don't understand each other 13.24.34 # Zagor: Then it might be that I don't grasp it. 13.24.51 # Zagor: the wiki doesn't explain how rockbox will use the format 13.25.16 # LinusN: true 13.29.10 # I think both solutions are not too far apart. Iiuc, the wiki described format is something like that: 13.29.54 # First part is (apart from the table pointers) the raw data, one entry per song with all fields. 13.30.47 # After that there are several indices, but with only one entry for all raw data entries, containing an array of pointers to the data 13.31.57 Join Tang [0] (tristang13@c211-28-75-247.frank1.vic.optusnet.com.au) 13.31.59 # My approach would also index the raw data, but with one index entry per raw data entry. This requires only one pointer to the raw data, and therefore avoids the problem with large pointer arrays 13.32.35 # why is a larges arrays a problem? 13.32.38 # As the index entries for the same key value would be adjacent, this should not create additional overhead 13.33.26 # Searching the index would be fastest if the whole index is loaded into ram. That will be obviously more difficult with large pointer arrays per entry 13.33.58 # the tables are not intended to ever fit in ram 13.34.35 # since they are sorted and fixed-size, we don't need an index to find a position 13.35.09 # Imho the tables towards the end *are* indices 13.35.19 # And: you always need to search somewhere. Otherwise, how am I supposed to find an album if I enter a string? 13.35.56 # yes, for freetext searching we have to use real search. but that is linear searching, which is another issue. 13.36.46 # We don't need linear search, unless we want to support real substring search. 13.36.48 # there are very few optimisations available in freetext searching 13.36.55 # we do want substring search 13.38.01 # And for linear search (substring), fitting the index table into ram should really boost performance 13.38.07 # Hello 13.38.21 # hi 13.38.25 # yes, but we won't ever be able to do that. there will always be more song name data than we can fit 13.38.31 # hi tang 13.38.52 # especially since we want to be able to browse and search while music is playing... 13.39.27 # for the first step, we are only working on database *browsing* 13.39.32 # Um, my nick is supposed to be Kuros - I posted a few ...replies on the rockbox forum - I'm about to take apart my iriver H340 13.39.53 # good luck with that :-) 13.40.01 # LinusN: yes, but searching is trivial to add 13.40.16 # Tang: sounds good. have you got a flatbed scanner? 13.40.50 # We'll see how we go - (yes I have one of those) that other guy had a bit of trouble 13.40.59 # Zagor: my point was that amicann was talking about searching and you were talking about browsing 13.41.35 # LinusN: well not really. we were both talking about browsing. he just wanted to use searching as part of the datafinding algorithm (afaui) 13.43.04 # some proof-of-concept is probably in order 13.43.14 # I don't need browsing at all for artist/album/genre. I already have that. But searching might be useful. 13.43.18 # "show me the code" :-) 13.43.25 # yes, i'm writing some code now 13.44.41 # amiconn: aha, so you were in fact talking about searching all along? that would explain our confusion! :-) 13.46.14 # Yes, but searching might also be involved for browsing with more than 1 selection criteria 13.46.23 # yes 13.47.54 # (Or adding more and more lookup tables - imagine that for every combination of 5 or more criteria!) 13.48.10 # That's why I suggested to have 1 index per field. The index table would be relatively small, and therefore searchable in a reasonable time 13.48.10 # see "unsolved issues" :) 13.48.15 # many lookup tables isn't a problem imho 13.48.34 # no but we can't solve it with just lookup tables 13.48.57 # or if we can, tell us how :) see the wiki for a case. 13.49.38 # And the create-indices-on-the-box has another reason (and this is one that could convince me to actually use the db) - adding dynamic info from playback, as kurzhaarrocker suggested 13.50.22 Join alx5000 [0] (~usuariouc@salasrt.alumnos.unican.es) 13.50.32 # hi 13.50.59 Join Zagor_ [242] (~bjst@labb.contactor.se) 13.51.06 # amiconn: i think dynamic info should be in a separate database 13.51.27 # alx5000: hi 13.51.53 Quit Zagor (Broken pipe) 13.51.58 # ive got a simple question about iriver's h series processor... i was just wondering 13.52.51 # wondering what? 13.52.54 # if it would be powerful enough to play video files 13.53.03 # probably 13.53.08 # but you' 13.53.31 # i'd be inclined to suspect you wouldn't get a decent framerate out of the lcd screen 13.53.48 # ashridah: why not? 13.53.52 # LinusN: Yes, although it still has to be connected to the static part in some way 13.54.00 # amiconn: yes 13.54.09 # we play video on the 12MHz archos today. the iriver will be a piece of cake. 13.54.45 # the lcd connection is parallel on the iriver, gives us quite a lot of bandwidth 13.54.46 # (if anyone wants to do it, that is. it's not exactly a #1 priority...) 13.55.18 # LinusN: ah, is it? kinda had the impression it wasn't. 13.55.57 # from the schematics? 13.56.11 # Zagor_: how fast is iriver's? 13.56.13 # no, the update rate of some things. ;) 13.56.27 # but that's probably just a poorly written bit of update code in the normal firmware 13.56.44 # alx5000: we can adjust the cpu frequency up to about 140MHz IIRC 13.56.56 # but we will probably stay around 70 13.57.10 # unless we want to encode ogg ;) 13.57.16 # ooooooh 13.57.19 # that'd be nice 13.57.25 # with emulated floating point... 13.57.27 # is there an integer-based ogg encoder? 13.57.29 # no 13.57.33 # ah. 13.57.45 # LinusN: can you kill Zagor. i'm not allowed to get op for this nick 13.57.46 # so we can call video playing a feature, not a dream, then? 13.57.55 # alx5000: a possible feature 13.57.58 # does anybody know of a decent real-time mp3 encoder except Shine? 13.58.05 # * ashridah hands alx5000 a text editor and a compiler 13.58.14 # ok, thank you very much, youve made my expectations grow :) 13.58.15 Mode "#rockbox +o LinusN " by ChanServ (ChanServ@services.) 13.58.29 # hehehe 13.58.45 # Zagor_: Zagor is not here according to my client 13.58.58 # ah, it left 13.59.06 Nick Zagor_ is now known as Zagor (~bjst@labb.contactor.se) 13.59.58 # oh, theres another stupid thing... my videocamera can output video and sound through a jack-2-rca cable... could this be coded in the firmware or is it hardware related? 14.00.48 # well... in theory we could perhaps do something with it since we've got straight input. but i just made jokes about encoding og... 14.00.53 # ogg 14.01.12 # that's a point. is there a standard for outputting video via optical out? 14.01.36 # how does gmini400 do it? 14.01.39 # none that i know of. but i'm no video guru. 14.01.48 # alx5000: dedicated ports and hardware. 14.02.08 # heheh ok, thats it, then 14.02.37 # wish we could have both firmware and hardware upgrades :D 14.03.15 # free hardware is a bit harder to realise than free software :) we need some serious physics innovation first. 14.03.40 # hehe 14.03.41 # i suggest that you hold your dreams a while, otherwise you'll be disappointed with the first iriver verison of rockbox 14.03.58 # it will be very basic 14.04.24 # i know, but now im stuck in iriver's firmware 14.04.29 # and that... sucks... 14.04.49 # anything greater than zero is something to point out... 14.05.24 # im reading what youve done with archos so far, and im quite amazed... 14.06.50 # btw, what does Speaking Menus Support mean? 14.07.07 # the menu options are spoken 14.07.11 # a voice 14.07.21 # so you can go through them "blindly"? 14.07.32 # it's a feature mainly for the blind 14.07.44 # but it's nice when you're driving a car as well 14.08.00 # i see.. :O 14.08.59 # i hate clips 14.09.35 Join elinenbe [0] (~elinenbe_@65.115.46.225) 14.10.44 # are you focusing on H100 series? 14.12.00 # yes 14.12.13 # Tang: clips? 14.12.54 Quit alx5000 ("Download Gaim: http://gaim.sourceforge.net/") 14.13.48 Join alx5000 [0] (~usuariouc@salasrt.alumnos.unican.es) 14.14.48 # back again... 14.15.03 # yeah, those silly little plastic things you have to push a bit to disengage the chip board 14.15.37 # heh 14.22.05 # sorry for asking so much, but... how much storage space / memory do you have in h100 for firmware? 14.22.21 # 2MB flash 14.22.27 # aha... 14.22.41 # and then a whopping 32 MB ram... 14.23.04 # and how much of those 32 are used during normal playing? 14.23.12 # all of it 14.23.16 # ok :D 14.23.21 # we always use all ram 14.23.44 # more ram just means larger buffers for mp3 etc 14.23.54 # and less disk activity 14.24.02 # less frequent anyway ;) 14.24.08 # meaning longer battery life 14.25.24 # thats a point... 14.27.31 # LinusN: how are your h100 commits coming? 14.28.03 Join langhaarrocker [0] (~none@p50876588.dip0.t-ipconnect.de) 14.28.04 # haven't had time to test drive the code on the target 14.28.24 # (baan sick, actually) 14.28.27 # been 14.30.36 # huge mpeg buffer! me loves it 14.30.38 Nick langhaarrocker is now known as kurzhaarrocer (~none@p50876588.dip0.t-ipconnect.de) 14.32.15 Nick kurzhaarrocer is now known as kurzhaarrocker (~none@p50876588.dip0.t-ipconnect.de) 14.32.28 # got a haircut? 14.33.53 # Yes, I entangled myself, but thanks to nickserv I'm free again. 14.36.09 # obviously the people who fix up these things have about seven hands... 14.36.48 # I've just come to a revelation - the front cover comes off as well as the back 14.38.17 # * kurzhaarrocker passes Tang an electric axe 14.39.22 # thanks - as much as I'd like to right now, I still want to listen to music later 14.39.46 # heh 14.43.37 # Something completely else: I know there's an out of date _plugin_ for editing id3 info. If it's a plugin - how can we edit the id3 info while recording? bummer. 14.44.50 # you mean right now, or conceptually? 14.45.10 Part alx5000 14.45.28 # As the plugin is out of date: conceptually. Should we allow plugins while recording? 14.46.06 # Or should id3 editing - just like recording - be considered part of the firmware? 14.47.02 # well we can't edit the actual tag while recording, since we don't want to mess with the file. but we could edit a dummy file, from which the tag is copied after recording is complete. 14.47.30 # I'm not sure how much the gui thread is part of the recording process, if any. 14.48.18 # as soon as it comes down to _triggered_ recording there is a problem with that approach of mine. 14.48.52 # Zagor: We could hold the (edited) tag in memory. It is only a few 100 bytes 14.49.44 # * Tang 14.49.53 # ... especially as the tags for freshly recorded files don't contain any bitmaps and stuff... 14.49.53 # yes, but we have no mechanism to pass memory between the core firmware and a plugin. 14.50.18 # i'd like to use the same editor for new recordings and regular files 14.50.36 # and the easiest way is probably to use a dummy file for recording 14.50.46 # * Tang scratches the itch to throw the iriver out the window 14.50.51 # why is it necessary to edit the tag while recording? 14.51.01 # * Tang sighs 14.51.08 # can't that wait until afterwards? 14.51.10 # Because you have time while you record, LinusN 14.51.40 # It should be fairly easy to implement 14.51.44 # Zagor: Then make it part of the core 14.52.00 # Tang: more clips? ;) 14.52.07 # the VBR info is updated when the recording ends, the ID3 tag could be changed at that time 14.52.08 # The best I can do for the moment is tell you what harddisk it's got... but that doesn't help, does it 14.52.25 # i think an id3 tag is an ideal candidate for a plugin 14.52.27 # Tang: not really 14.52.28 # editor 14.52.35 # an editor, yes 14.52.47 # hmm 14.53.06 Join elinenbe_ [0] (~elinenbe_@65.115.46.225) 14.53.07 Quit elinenbe (Read error: 104 (Connection reset by peer)) 14.53.10 Nick elinenbe_ is now known as elinenbe (~elinenbe_@65.115.46.225) 14.53.48 # And that editing becomes really interesting when you have timed recording and a file split happens while you're editing :) 14.54.20 # no problems if we use a dummy file 14.56.01 # starting a plugin while recording is a bad idea imho 14.56.14 # the time split is done by the main thread 14.56.50 # would it be ugly to move? 14.56.54 # i think a simple interface for entering title and artist in the recording screen would be sufficient 14.57.09 # then a "real" editor in a plugin 14.57.58 # i remember having difficulties moving the split to the mpeg thread, but i can't remember what it was 14.59.19 # i think the split belongs in the mpeg thread 14.59.35 # With volume triggered recording it would be difficult to - unless we want separate read outs for the peak meter and trigger detection. 14.59.38 # the main thread should just monitor the recording 14.59.53 # kurzhaarrocker: true 14.59.57 *** Saving seen data "./dancer.seen" 15.01.38 # * kurzhaarrocker still thinks that the peak value read out should have its own thread. 15.02.08 # because...? 15.03.21 # For example the peakValueThread could fire trigger events and the peak meter might become more precise. 15.03.47 # because...? 15.04.40 # because we could read out more often because the read out would be decoupled from updating the gui. The peak meter wouldn't poll, just draw. 15.05.25 # i don't get it, the gui takes just as long to update regardless if the peak meter is in a separate thread or not 15.06.08 # Don't we have tick threads? (it's been a while...) 15.06.13 # no 15.06.36 # simple round-robin cooperative threads 15.07.37 # * kurzhaarrocker shuts up for a while 15.07.52 # :-) 15.09.54 # LinusN: There are tick tasks... 15.10.55 # * kurzhaarrocker sees something strange called IMIAO which he thought was something thread related, triggerd by a hw timer via interrupt. 15.12.21 # kurzhaarrocker: IMIA0 is the isr called by timer 0 interrupt 15.13.14 # And is it an absolute nono to use that every nth time to read out the peak value? 15.15.52 # You should not do such a thing directly in the isr. Instead, use tick_add_task() to add a function that is called every 10 ms 15.16.24 # amiconn: i wrote the kernel, i know that you can add a "tick task" 15.16.48 # but a task that talks i2c with the MAS is out of the question 15.17.16 # Due to timing? 15.17.37 # a MAS conversation can take several milliseconds 15.17.43 # LinusN: Ah ok. Of course i2c from interrupt is not allowed, silly me 15.18.00 # and the i2c driver uses a locking mechanism that can only be run by background threads 15.18.49 # I should know that (from my backlight dimming experiments); using i2c from interrupt may even lock up the box as soon as lcd access is going on in parallel 15.18.58 # still, i can see one valid reason to have a separate thread for the peak data 15.19.31 # and that is the peak trigger event business 15.20.17 # Currently I implemented that using a callback function in the peak meter code. 15.21.28 # -> works only when the peak meter is being displayed. 15.23.31 # That thread would only be needed when triggered recording is actually used. Threads can be started and ended dynamically iirc 15.27.40 # The thread would be needed too as soon as a peak meter is displayed or we'd end up in separate read outs for peak meter and trigger again. 15.30.10 # Okay 15.34.07 # The thread may also be present all the time (or as soon as the peakmeter is used for the first time), but then it should only read the values when necessary 15.34.34 # gotta go 15.34.36 # cu guys 15.34.52 Part LinusN 15.36.56 Quit ashridah ("sleep") 15.40.28 Join zapotech [0] (zazz@dh051-118.chem.sunysb.edu) 15.41.06 # ok, I don't think I can scan this, but I have some photos of it 15.42.27 # nice. uploaded anywhere? 15.42.53 # Umm... 15.43.32 # I don't know where to upload 'em ...I'm not sure of the best way.. 15.43.46 # you can upload them to our wiki if you like 15.46.07 # ok... sounds ok - if I run into the hard wall of confusion and ignorance, I'll give you a bell 15.49.42 Join Audiophil [0] (~dsads@213.236.154.41) 15.49.58 # er dere svenske? 15.50.00 # tøft :D 15.51.24 # Audiophil: some of us are, but the majority isn't. so we speak english here. 15.51.33 # alla svenskar suger fett..!! :) 15.51.39 # ok 15.52.14 # regarding iriver, will it be possible to reinstall the iriver software if you somehow want to do that? 15.52.55 # yes 15.54.08 # It should work the same as the usual firmware upgrade - I accidently upgraded the firmware for my iriver to two releases before the one that came in the box 15.54.17 # sweet 15.54.36 # so how's the status on an iriver release? 15.55.09 # far away. we've just barely ran any code on it yet. 15.56.39 # maybe something early can be release around christmas, if things are going well 15.57.25 Part kurzhaarrocker 15.58.20 # oh :/ 15.58.28 # well, keep up the good work 16.06.17 Join Lynx [0] (lynx@134.95.189.59) 16.22.44 Quit Lynx_ (Read error: 110 (Connection timed out)) 16.22.45 Nick Lynx is now known as Lynx_ (lynx@134.95.189.59) 16.23.54 Quit Audiophil (Read error: 238 (Connection timed out)) 16.47.20 Join mecraw_ [0] (~lmarlow@69.2.235.2) 16.56.34 # ok, I've hit that wall.... this is the first time I've ever put something on a wiki before - I've only ever read up on stuff before 16.57.11 # i see you registered sucessfully 16.57.59 # i suggest you upload to the IriverInfo page. we can always move it later if we want. 16.58.12 # go to that page, then click "attach" and follow the instructions 16.59.58 *** Saving seen data "./dancer.seen" 17.16.09 Quit einhirn (Read error: 54 (Connection reset by peer)) 17.16.21 # ok 17.22.00 # Is there a size limit? 17.25.55 # i don't think so 17.25.59 Quit gromit`` (Read error: 110 (Connection timed out)) 17.26.07 Join gromit` [0] (~gromit@ALagny-151-2-7-194.w82-121.abo.wanadoo.fr) 17.26.13 # are they huge? 17.27.03 # not too huge - but they have different focus on different spots, so there is a few of them 17.27.26 # ok 17.27.28 # 19Mb ? 17.27.34 # each? 17.27.43 # alltogether 17.27.47 # ok, no problem 17.30.33 # i've gotta go. see you later. 17.30.34 Part Zagor 17.33.14 Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) 17.36.42 # Goodnight to those people who saw me log on - and good night to the computers of whos owners neglect to turn off 17.37.06 # ....I'm tired. 17.38.08 Part Tang 17.40.48 Quit Lynx_ (" HydraIRC rocks! -> http://www.hydrairc.com <-") 18.05.39 Quit einhirn (Read error: 54 (Connection reset by peer)) 18.08.31 Join methangas [0] (methangas@0x50c61d43.virnxx10.adsl-dhcp.tele.dk) 18.11.35 Join webguest75 [0] (~c7e73280@labb.contactor.se) 18.11.45 # hello 18.11.52 Quit elinenbe (" I love my HydraIRC -> http://www.hydrairc.com <-") 18.12.25 # small question: why is the usb cable for the archos not standard? 18.12.36 # is there any good tech reason? 18.14.24 Join millow [0] (~millow@67.227.adsl.i4surf.net) 18.25.06 Quit webguest75 ("CGI:IRC (EOF)") 18.41.19 Part amiconn 19.00.02 *** Saving seen data "./dancer.seen" 19.24.36 Join ScrpWork [0] (~Naikel@naikel.ogangi.com) 19.24.44 # hi fellas 19.25.41 Part millow 19.40.46 Join _aLF [0] (~Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) 19.40.51 # <_aLF> hi 20.03.41 Join dropandhop [0] (~43646aab@labb.contactor.se) 20.56.53 Join Farbrausch [0] (~d95871be@labb.contactor.se) 20.58.43 # hello 21.00.04 *** Saving seen data "./dancer.seen" 21.00.39 Quit Farbrausch (Client Quit) 21.03.28 # nobody ever talks here? 21.16.20 Join PoDDaN^ [0] (~d9d111c6@labb.contactor.se) 21.16.26 # hi all 21.16.40 # can anyone help me out with one thing? 21.26.42 Quit _Lucretia (Connection timed out) 21.27.03 Join _Lucretia [0] (~munkee@abyss2.demon.co.uk) 21.27.56 Quit PoDDaN^ ("CGI:IRC") 21.34.28 Join kurzhaarrocker [0] (~none@c-134-121-140.d.dial.de.ignite.net) 21.35.22 # My battery has burst. 21.38.02 # anyone had an archos recorder 2.0 just not turn on or show any signs of life after leaving it sit around for a month .. (and after charging it to make sure it was dead batteries :) ) 21.38.54 # Dead batteries are the most common cause for any hw fault of the thingies. 21.39.36 # with the power adapter plugged in it should power on even without batteries.. it doesn't do that either.. 21.41.05 # The adapter alone doesn't provide enough power to operate the jukebox. Without batteries it won't spin up even with the adapter connected. 21.41.30 # but the screen lights up with the adapter plugged in 21.41.50 # that doesn't require the batteries.. or at least so i've read 21.41.54 # Yes, but probably there's not enough current to make the hd work. 21.42.53 # The V2 unit is that thingie with the built in Lithium batteries, isn't it? 21.43.12 # <_aLF> yes 21.43.13 # but i can't even get the screen to light up.. from what i've read it should at least do that.. 21.43.21 Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) 21.43.23 # it has 4 replaceable batteries 21.44.29 # Have you tried another set of batteries? 21.44.54 # i just found out this thing wasn't working like 2 hours ago.. i haven't opened it up yet to get to the batteries.. 21.45.00 # i'm about to do that.. 21.47.23 # hi 21.47.57 # hi 21.48.06 # how's it going over here 21.48.31 # It's quite calm now 21.50.22 # what are the latest new on H120 unscramle 21.50.24 # unscramble 22.01.50 # wouldn't you just know it?! i can't find a screwdriver small enough to fit these screws.. 22.02.49 # now i could *probably* use a hammer to get it open but that may lead to *other* issues with the device 22.05.12 Quit methangas (" I love my HydraIRC -> http://www.hydrairc.com <-") 22.05.19 # archoses are supprisingly hard to open with a hammer... 22.06.02 # if this isn't working in the next few days i just may find out for myself just how hard.. 22.08.48 Join njsges [0] (~njsges@adsl-18-121-126.sdf.bellsouth.net) 22.08.57 # afternoon 22.16.10 Quit kurzhaarrocker (Read error: 110 (Connection timed out)) 22.19.38 # hey all! 22.19.57 # any suggestions as to how i can help the crew with the iriver...i can't code 22.22.36 # give them an H120 for free 22.22.43 # that'll help them out a lot 22.23.04 # consider a donation 22.23.20 # to allow us to buy more hw to work with 22.30.25 # anyone available to answer a few questions about archos and iriver pmp's? 22.30.45 # just shoot them, maybe somebody knows 22.30.47 # pmp? 22.31.59 # personal music player? 22.33.49 # the personal media players 22.34.14 # i'm looking to get one to use in conjunction with my digital camera and storing images 22.34.34 # as well as use it to listen to music as well as to record meetings 22.34.43 # any suggestions on what to get? 22.35.01 # how can yo use an mp3 player in conjuction with a digital camera? 22.35.04 # neither archos nor iriver will help you with the camera problem 22.35.20 # ScrpWork: if it could server as a usb host 22.35.24 # serve 22.35.53 # will either one work as a direct storage device from my dig camera to the device? 22.35.58 # via usb 22.36.11 # or will one of the iriver h120 or h320 work? 22.36.13 # neither one 22.36.21 # no 22.36.22 # none 22.36.39 # the archos i believe does have a card reader on tthe side 22.36.42 # they are slaves, and so is the camera 22.37.06 # oh, right some newer multimedia models have such 22.37.15 # I can't speak about them, as rockbox doesn't run on them 22.37.33 # it runs on the earlier versions of the archos products 22.37.37 # correct? 22.37.52 # yes 22.38.11 # would any of the earlier models be a better fit for what i'm trying to do? 22.38.43 # just about every unit on the market can do the other things, hardly any can store images from a camera 22.38.49 # I mean directly over usb 22.38.56 # ok 22.40.17 # rockbox supports the early jukebox players 22.40.25 # not the gmini or av's 22.40.37 # " Rockbox is an Open Source replacement firmware for the Archos Jukebox 5000, 6000, Studio, Recorder, FM Recorder and Recorder V2 MP3 players." 22.40.59 # * Bagder detects a lack of "Ondio" in there 22.44.18 # and here are the hard facts: http://www.rockbox.org/docs/devicechart.html 22.44.24 # on all supported models 22.53.25 # cool 22.53.28 # thank you 22.54.12 Join iRiverMan [0] (~acbe7dfd@labb.contactor.se) 22.54.17 # hi 22.56.30 Part njsges 22.56.56 # yo 23.00.08 *** Saving seen data "./dancer.seen" 23.08.01 Join Gamefreak [0] (~Gamefreak@pcp0010543349pcs.cnorth01.va.comcast.net) 23.08.10 # Heya. 23.08.33 # yo 23.08.54 Quit gromit` (Read error: 104 (Connection reset by peer)) 23.09.02 # Just a tad curious, being the slave to the oppression that is iRiver, when I can expect to see the Rockbox port. 23.09.18 # And for that matter if I can help. 23.09.31 # <_Lucretia> Gamefreak, think yourself lucky, at least there's a port in progress for iRiver :-( 23.09.38 # lol 23.09.52 # I would just like a working simulator and some bit of documentation so I can make my own firmware 23.09.57 # I have to wait a lot for that as well heh 23.10.36 # the simulator works for iriver 23.10.51 Join gromit` [0] (~gromit@ALagny-151-2-7-194.w82-121.abo.wanadoo.fr) 23.11.06 # or, at least is should 23.11.09 # it 23.11.55 # Gamefreak: there's basically only one developer working on iriver code, so it is gonna take a while before there will be anything reallt fun to see 23.14.19 Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) 23.16.24 # after all hardware functions are documented some people can code an Hxxx simulator :) 23.17.39 # we already have one 23.17.39 # read my words 23.17.39 # we have a set of APIs already 23.18.55 # docs/API is a basic embryo at some docs 23.19.35 # correct me if I'm wrong but I thought you had a Motorola 5249 emulator 23.19.52 # not a Hxxx simulator (simulates LCD, keyboard input, audio output, etc) 23.20.06 # we have a simulator 23.20.11 # of the whole thing? 23.20.13 # that simulates the lowlevel stuff 23.20.16 # oh 23.20.21 # and makes it possible to write code on host 23.20.27 # we've had it for years 23.20.36 # and it has been adjusted to simulate iriver as well 23.20.38 # what about the iRiver's remote? 23.20.49 # that is still left todo 23.21.02 # since the LCD on the remote mirrors the main LCD 23.21.09 # it doesn't 23.21.16 # it only does that with irivers fw 23.21.22 # we don't have to do that 23.21.44 # so does that mean the LCD on the remote becomes redundant? 23.21.44 # afaik 23.21.47 # well but it would be cool if it simulates the whole thing, so you can see a JPEG of a iRiver and use a directory of the HDD as the simulated HDD of the stuff 23.21.49 # uh? 23.22.05 # you put the original firmware and you could even get audio through your soundcard emulating the DACs 23.22.09 # ScrpWork: that is basically what we have 23.22.27 # ScrpWork: no, that makes it an emulator and that we don't have ;-) 23.22.37 # iRiverMan: why would that be? 23.22.45 # Bagder do u have an iriver? 23.22.52 # why? 23.23.06 # the iriver isn't very good at shuffling playlists 23.23.11 # always plays the same songs 23.23.16 # but that would be great :) if all the hardware functions are documented you can find some people interested in coding a full emulator 23.23.17 # No problem shuffling the HD though 23.23.20 # you make no sense iRiverMan 23.23.26 # why not? 23.23.32 # shuffling in an iRiver is just non existant. 23.23.35 # it doesn't have randomness 23.23.39 # since it doesn't have a clock 23.23.39 # it does 23.23.41 # so they say 23.23.43 # rockbox will 23.23.53 # I have an H120 that's why I'm here in this very channel :) 23.23.55 # iRiver does have a shuffle mode 23.24.01 # doesn't work very well on playlists though 23.24.02 # yeah but shuffle without randomness 23.24.09 # doesn't work very well on anything 23.24.10 # you have lost me 23.24.12 # not even on directories 23.24.29 # shuffle only put the songs in the same order and makes you think it randomize them 23.24.44 # but no, just changed the order and it will always be the same order until you delete or upload a new song 23.25.00 # well i found a way is to manually shuffle a playlist in Winamp 23.25.02 # so it's shuffling without randomness hehe 23.25.05 # yeah 23.25.07 # that's a workaround 23.25.25 # But i still think its a better machine than the archos 23.25.28 # people shuffle the playlists several times each and upload all the results to the H120 23.25.35 # but that sucks 23.25.41 # it certainly is lame 23.25.41 # of course it's the best mp3 player ever 23.25.52 # i like the construction of the iriver 23.25.57 # much better than others 23.27.36 # yeah 23.27.43 # well an emulator would be great 23.27.49 # I could even help myself to code one 23.27.49 # i have an iriver ihp-120 23.28.01 # then we can write our own firmwares based on the basic stuff 23.28.19 # so write one! 23.28.49 # it'll be a major job 23.28.50 # I would need a precise documentation of the functionality of all the hardware. An emulator has to emulate everything, not only the CPU, but all the other controllers 23.29.05 # work your way ahead 23.29.10 # I would suggest a subteam of volunteers to do that and not bother the core developers 23.29.10 # read the docs we have 23.29.50 # I have, but I'm still unsure heh 23.29.56 # so are we 23.29.57 # anyway I gotta go home maybe I'll connect from there 23.30.03 # cya :) 23.30.04 Quit ScrpWork ("Scorpius MultiServer Script v0.1 for mIRC 6") 23.30.12 Quit Gamefreak (Read error: 110 (Connection timed out)) 23.30.30 Quit dropandhop ("CGI:IRC") 23.37.30 Join gromit`` [0] (~gromit@ALagny-151-2-7-194.w82-121.abo.wanadoo.fr) 23.37.31 Quit gromit` (Read error: 104 (Connection reset by peer)) 23.40.32 # time to sleep 23.40.38 # night 23.46.34 Join Lucretia_ [0] (~munkee@abyss2.demon.co.uk) 23.55.50 Quit _Lucretia (No route to host)