--- Log for 05.07.105 Server: brown.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 24 days and 22 hours ago 00.00.08 # okay 00.00.11 # thats just odd.. 00.00.14 # it wasn't working 00.00.21 # i checked whether the runtime database was turned on 00.00.24 # i went to usb mode 00.00.27 # came back from usb mode 00.00.29 # and now it suddenly works.. 00.00.43 # * HCl dislikes bugs that "disappear" 00.01.09 Join webguest18 [0] (~d4406110@labb.contactor.se) 00.01.13 # my rockbox.rundb is 8 bytes 00.01.23 # seems... small 00.01.29 # might need a new hd for that Bagder 00.01.36 # :-) 00.01.37 # * HCl commits 00.01.46 # Bagder: archos or? 00.01.52 # h140 00.01.54 # amiconn added an option that has to be turned on 00.01.57 # its in playback options 00.02.04 # played for ~90 mins today 00.02.06 # 8 bytes means it just has a header 00.02.15 # I enabled the option 00.02.17 # okay 00.02.21 # then i think we're having the same bug 00.02.24 # I'll doublecheck 00.02.27 # btw - i think my hdd IS knackered, you know.. :-( i'll see if i can get a warranty replacement for it, if not I'll upgrade to 30GB :-) 00.02.27 # same 00.02.40 Join PaulJ [0] (~PaulJ@vpn-3040.gwdg.de) 00.02.52 # yea 00.02.56 # pill: that feature already exists, look up the definitions of 'Insert', 'Insert Next', 'Insert Last' 00.02.57 # there's something wrong with the rundb init 00.03.02 # it works after plugging in usb 00.03.06 # but it doesn't get initialized on bootup 00.03.15 # * HCl goes to check 00.03.36 # um. 00.03.37 # yea.. 00.03.39 Join Infirit [0] (~infirit@82-217-42-235.cable.quicknet.nl) 00.03.41 # I have the option enabled 00.03.42 # who removed the rundb_init o.o;; 00.03.45 Part webguest18 00.03.46 # checked now 00.03.50 # yea, the rundb init disappeared from the main init() 00.03.55 # * HCl goes to check cvs.. 00.04.05 Quit Infirit (Client Quit) 00.04.59 # can i check all the files that have been changed with a specific commit? 00.05.04 # amiconn moved the init somewhere, but broke it.. 00.05.26 # * HCl checks cvs log.. 00.05.30 # cvs doesn't really group files in a commit 00.05.51 # but you can "guess" based on the comment and timestamp 00.06.18 Join webguest85 [0] (~d49f4cf2@labb.contactor.se) 00.06.36 # yea, i found it anyways... 00.06.53 # i don't see why amiconns change would be erronous, but it does bug for some reason.. 00.07.03 Join LinusN [0] (~linus@labb.contactor.se) 00.07.06 # maybe its trying to init before the settings are loaded? 00.07.07 # i think thats it.. 00.07.25 # okay, looks like moving resume update to mpeg/playback threads works fine... 00.07.33 # rundb doesn't belong in tree though... 00.07.40 # would there be a reason it shouldn't be moved there? 00.07.50 # the tagdb does because its needed for browsing, but the rundb init has nothing to do with the tree structure 00.08.15 # HCl: yes, it is probably better off in a new file 00.08.29 # hardeep: not that I can think of 00.08.44 # amiconn or Linus might have opinions 00.08.53 # hrm.. 00.09.01 # the settings do get loaded before the call to the tree init though.. 00.09.01 Quit webguest85 (Client Quit) 00.09.02 # i don't really remember if there was a reason 00.09.09 # i'm confused to why its failing to init at bootup 00.09.18 # perhaps a will to only update rtc from one thread? 00.09.26 # ohhh! 00.09.28 # ofcourse. 00.09.41 # rundb_init *has* to be inited after audio_init or it won't work 00.09.58 # maybe it had to do with the separation of apps and firmware and settings are only available in apps? 00.10.12 # i worked around that by adding a playlist function that the mpeg thread calls 00.10.15 # HCl: surely the comments for that function explains that precondition? ;-) 00.10.52 # :P i just added the comment 00.10.59 # i know, writing documentation is on my todo list 00.11.09 # fixed in the bleeding edge build 00.11.24 # you and Slasheri write about the same amount of comments in your code 00.11.27 # none 00.11.37 # :P sorry, i'll try to do better 00.12.05 # it isn't really a complaint at this point, merely a remark 00.12.09 # :p 00.12.15 # i'll try to do better anywho 00.12.24 # LinusN: If you wanted to look at it, I have a patch at http://hardeeps.freeshell.org/patches/resume.diff 00.12.37 # if you have no problems with it, i'll go ahead and commit 00.15.03 # putting runtime data in the id3 structure was a really good idea 00.15.08 Quit Moxon ("leaving") 00.15.16 # its really easy to access the runtime data of the current song, and just as easy to change it 00.15.18 # hardeep: the rtc may be accessed from two threads, please check if there's a mechanism to handle that 00.15.46 # LinusN: yeah, I was just looking... doesn't appear to be any protection around it 00.15.56 # how did i manage this.. 00.15.56 # make[1]: Warning: File `main.c' has modification time 2.4e+02 s in the future 00.16.17 # HCl: using nfs? 00.16.26 # no.. 00.16.37 # local file... just edited them with vim... 00.16.46 # weird 00.16.50 # i don't see why their modification dates would be in the future.. 00.16.51 # yea.. 00.16.52 # but vim is weird! ;-P 00.17.15 # LinusN: oh wait, rtc_write() calls i2c_begin() which takes a mutex 00.17.32 # hardeep: ah, yes 00.18.15 # hardeep: seems suitable you add a little comment about that 00.18.21 # when i add language strings, will english.lang do or do i have to add blanks for all the other languages.. 00.18.24 # ? 00.18.37 # HCl: english only is good enough 00.18.38 # Bagder: comments??? blasphemy! =) 00.18.39 # k 00.19.14 # HCl: the other languages will get the english versions until they provide their own 00.21.16 # ah 00.21.17 # k 00.21.47 Quit gromit` (Read error: 104 (Connection reset by peer)) 00.22.41 Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) 00.23.40 Quit west-acre ("—I-n-v-i-s-i-o-n— 2.0 Build 3515") 00.27.39 # * HCl wonders where to add a tag for playcount and rating 00.27.54 # most trouble i'm having is finding a spot where i can still put at least a sensible letter to use for it :P 00.28.16 Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 00.28.48 Quit cYmen_ (Read error: 104 (Connection reset by peer)) 00.29.28 # * Bagder fades away 00.30.26 # BADGER, NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOoooooooooooooooooooooooooooooooo!! 00.31.10 Nick courtc_ is now known as courtc (~courtc@adsl-158-10-231.asm.bellsouth.net) 00.31.11 # hmmm, the fading backlight made the boot loader hang/crash 00.32.02 Quit ghostiger (Remote closed the connection) 00.32.59 # ouch. 00.33.08 # darn 00.33.13 # i had to ask bagder a question 00.33.17 Join jlee [0] (~jlee@69-175-94-207.frdrmd.adelphia.net) 00.33.21 # who knows stuff about wpses 00.33.21 # about what? 00.33.22 # ? 00.33.28 # i need a very simple thing 00.33.36 # i just need to make a tiny own wps with a special tag i just made 00.33.38 # to test whether it works 00.33.44 # then do it 00.33.55 # * HCl guesses he'll go read the wiki 00.33.57 # i dunno how they work.. 00.34.06 # get the default wps from wps-display.c 00.34.21 # k 00.34.23 # thanks 00.36.39 # kind of scary how gcc does format string checking on snprintf.. 00.38.04 # HCl? 00.38.09 Join TCK [0] (TCK@81-86-98-38.dsl.pipex.com) 00.39.01 # yes? 00.39.03 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 00.39.33 Quit PaulJ (".") 00.43.22 # hardeep: i think you should commit the patch 00.43.42 # HCI scary in what way? 00.44.13 # LinusN: okay... I was just double checking that calling settings_save() from two different threads wouldn't be a problem and it looks like it's fine 00.45.43 # hah. 00.45.45 # thats pretty cool 00.45.52 # hardeep: in fact, periodic updates shouldn't be necessary anymore 00.45.56 # * HCl commits wps support for playcount and rating 00.46.08 # LinusN: why not? 00.46.22 # because we have "soft" poweroff for all platforms 00.46.37 # oh, right 00.46.54 # my wps shows playcount and rating now :) 00.46.55 # should i even bother with the settings_save() then? 00.47.02 # air - all i need; playcount: 4 rating: 9 00.47.04 # :) 00.47.10 # hardeep: i dunno 00.47.28 # i'll leave it in for now 00.50.05 # HCl: how do you rate it? 00.50.14 # in the context menu :) 00.50.24 # wps context menu 00.50.25 # that is 00.50.28 # lovely 00.51.03 # * HCl goes to rate all the best songs of his collection with a 9 :) 00.51.59 # might it be possible to add certain "graphic" tags? 00.52.06 # 9?! 00.52.14 # like a dot in the middle 00.52.15 # is the scale 0 to 9 ? 00.52.19 Nick thegeek_ is now known as thegeek (na@ti521110a080-2228.bb.online.no) 00.52.19 # 0-10 00.52.22 # 0 meaning no rating 00.52.31 # hmm 00.52.32 # HCl: i don't get it 00.52.34 # oh well 00.52.37 # LinusN: mm? 00.52.43 # thegeek: why? 00.52.46 # that's a big scale for something that subjective 00.52.46 # LinusN: what don't you get? 00.52.47 # I mean 00.52.52 # graphic tags 00.52.55 # sorry 00.52.58 # i'm being a bit vague 00.53.03 # hold on 00.53.05 # hard to choose between 4 and 5;) 00.53.48 # http://www.rockbox.org/twiki/bin/view/Main/MarkBright 00.54.00 # like that one is using - | and + in order to do some minor graphics 00.54.29 # and the one of jonnyDr (there's no link to it, but its above that one) has small dots 00.54.33 # but that dot isn't in all fonts 00.55.17 # * HCl tried that one but it ended up showing as some weird u 00.55.19 # :/ 00.55.35 # and people using ==== to create a seperator line 00.55.49 # it'd be better if we had simple graphic tags for that 00.55.57 # like draw line from there to there 00.56.18 # aha, now i understand 00.56.34 # but i don't see anything in the link you gave me 00.56.39 # sorry 00.57.03 # see how he uses |-+ to mimick some sort of folder structure..? 00.57.06 # in his screenshot? 00.57.24 # (screenshot?) 00.57.38 # um. 00.57.39 # http://www.rockbox.org/twiki/pub/Main/WpsGallery/MSB_WPS.png 00.57.39 # o.o 00.58.08 # doh 00.58.12 # i just noticed 00.58.14 # i posted the wrong link >.< 00.58.16 # sorry 00.58.30 # http://www.rockbox.org/twiki/bin/view/Main/WpsGallery#MarkBright 00.58.32 # thats the one i meant :X 00.58.36 # gomen nasai 00.58.48 # hm.. actually 00.58.54 # the wps gallery needs some work 00.58.59 # there are two html markbright tags in there 00.59.02 # and its taking the first one.. 00.59.12 # look at the one in the iriver section...... 00.59.33 # i see 01.00.15 # it'd be nice if we would be able to offer a way to do some minor graphics instead of forcing people to ascii art 01.00.26 # just a simple draw line from there to there would go a long way 01.00.58 # but i gotta go to sleep.. 01.00.59 # gnight. 01.01.25 # nite 01.07.42 Quit Sucka ("a bird in the bush is worth two in your house") 01.09.58 # * HCl has some bugs with id3 reading, wonders whether he created it.. 01.09.59 # ah well 01.10.01 # night 01.11.12 Join Data_OverLoad [0] (~Edward@CPE000c416e74a8-CM000a735f940c.cpe.net.cable.rogers.com) 01.11.17 Part Data_OverLoad 01.12.35 Join austriancoder [0] (~austrianc@80.120.117.30) 01.12.40 # hi all 01.12.44 # hey 01.12.45 # hey 01.12.46 # long time no see 01.12.47 # gnight 01.12.53 # night 01.13.46 # austriancoder: http://www.pemicro.com/index.cfm?targetURL=http://www.pemicro.com/products/product_viewDetails.cfm?product_id=106&menu_id=details&CFID=450301&CFTOKEN=81923511 01.14.04 # you want the 3.3V one, not the 5V 01.14.38 # fine.. this was one of the questions i wanted you to ask ;) 01.16.11 Join Peuc [0] (~peuc@jus25-1-82-225-15-160.fbx.proxad.net) 01.25.57 Quit Aison ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )") 01.27.00 # i'm doing a serious overhaul on the formatting of http://www.rockbox.org/twiki/bin/view/Main/CustomWPS BTW 01.27.16 # could take a while 01.27.30 # anyone need a quick edit lock release, just tell me :) 01.27.37 Join gromit`` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) 01.27.44 # what are you doing with it? 01.27.51 # its all in 
01.27.55 #        im changing it to tables 
01.27.58 #        looks far better
01.28.01 #        ah
01.28.17 Quit    gromit` (Read error: 104 (Connection reset by peer))
01.28.24 #        but it needs 
 around the wps tags
01.28.32 #        so its taking a lot of changes to do 
01.29.04 Join    xen` [0] (nop@stg25-1-82-238-117-1.fbx.proxad.net)
01.29.52 Quit    cYmen ("zZz")
01.30.20 Quit    hicks (Remote closed the connection)
01.32.16 #        the SYS_POWEROFF seems to work fine
01.32.57 #        the viewer plugin now automagically saves the settings before the power is cut
01.32.59 #        how much usable is the recording function in the debug menu? can it be used in the real world safely?
01.33.21 #        tvelocity: sure, but it seems to overwrite the same file every time
01.33.30 #        that's no problem to me
01.33.52 #        i'm currently testing for how long it can record withe the battery full
01.35.25 #        any known issues with it? my roommate wants to record a live event
01.37.50 #        looks like it doesn't split long recordings into multiple files yet
01.38.28 Quit    markun ()
01.38.43 #        so you will probably hit the 2gig limit before the battery runs out
01.38.54 #        oh
01.38.55 #        :/
01.39.31 #        silly microsoft
01.39.31 #        i think 2gigs are enough though, he wants to record for ~3 hrs
01.39.52 #        i wonder what the largest available HDD size was when the fat32 format was designed
01.40.08 #        is there any record glitch, like in iriver FW, or was that a software problem?
01.40.22 #        software
01.41.05 #        the current test in rockbox has a "glitch" in the beginning of the recording, but the rest of it should be nice and quiet
01.41.15 #        great!
01.41.34 #        it suits my need perfectly ;)
01.41.39 #        haven't tried it myself though, i'm just repeating what others have said
01.42.29 #        what will happen when it hits the 2gig limit? will it stop, or will it crash and destroy mankind?
01.44.26 #        iirc, rockbox will go on until it hits 4gig, but the results are, so to say, "undefined"
01.44.34 #        AAAAAAAAAHHHHHHHHHHHHHHHHHHHH
01.44.42 #        wiki is annoying
01.44.46 #        heh let's find out:P
01.44.46 Join    Cassandra [0] (~cassandra@82-70-230-150.dsl.in-addr.zen.co.uk)
01.44.54 #        tvelocity: backup first
01.45.10 #        i cant use | in a table without it forming a border, EVEN WITH 
 OR  AROUND IT!!!!!!!!!!!
01.45.15 #        i haven't anything i want in it
01.45.33 Join    EoS [0] (EoS@chello212186071171.1.14.vie.surfer.at)
01.45.40 #        hello
01.45.42 #        besides, it's allready at 2hrs and 50 minutes... i won't stop it now!
01.45.43 #        'lo
01.45.47 #        EoS: hi
01.45.50 #        Hmm..  bit of a noob question but, ..    I just tried adding support for pcm vu meters on iriver, and with the new code and plugins installed on my player, the unit turns itself off moments after turning on.   Anything obvious?   Clearly I just bungled somewhere..
01.46.22 #        i just saw a pic of the rockobx loading on a gmini 120, is it fully funtional for those players now?
01.46.29 #        nope
01.46.31 Quit    Cassandra (Read error: 131 (Connection reset by peer))
01.46.34 #        not even slightly
01.46.35 #        stripwax_: perhaps not that obvious
01.46.52 #        i think...
01.47.06 #        ah too bad..
01.47.16 #        EoS: the gmini developer(s) have been away for quite some time
01.47.18 #        LinusN - I can't think of anything that would cause it to just turn itself off :-(
01.47.35 #        stripwax_: how quick?
01.47.35 #        yeah that pic on the rockbox page is from jan 05
01.47.48 #        http://www.rockbox.org/twiki/bin/view/Main/GminiPort
01.48.00 #        thx n00by
01.48.17 #        :(
01.48.20 #        stripwax_: is the patch online somewhere?
01.48.48 Nick    n0bby is now known as _Mark (~fake@40-218.207-68.tampabay.res.rr.com)
01.48.50 #        i could run it with the bdm
01.48.55 #        LinusN - no, sorry.   About three seconds?  don't get as far as the rockbox logo
01.49.02 ***     Saving seen data "./dancer.seen"
01.49.41 #       <_Mark> thats a pretty nasty bug just for a VU meter :P
01.50.08 #        LinusN - I'll take another look tomorrow night, and I'll try and get a patch together then
01.50.10 #        _Mark - heh
01.50.14 #        gnight
01.50.49 #        lol oops sry i called u n00by i misread :)
01.50.53 #       <_Mark> yeah
01.51.04 #       <_Mark> i've used the nick "nobby" for years and everyone does
01.51.12 #        lol
01.51.28 #        its just too tempting to misread
01.51.43 #       <_Mark> It was "nobby nobbs", the discworld character
01.51.55 #       <_Mark> but that was too long for repeated typing so i shortened it
01.52.00 #       <_Mark> bad move
01.52.03 Part    stripwax_
01.52.19 #        im prolly getting a iriver h140 tomorrow :)
01.52.58 #        hehe
01.52.58 Join    Cassandra [0] (~cassandra@82-70-230-150.dsl.in-addr.zen.co.uk)
01.53.14 #        discworld <3
01.54.35 #       <_Mark> indeed
01.56.10 #       <_Mark> arg
01.56.14 #        :)
01.56.20 #       <_Mark> this bug in the wiki parser is pissing me off
01.56.35 #        ok thx for the info guys, im going to bed
01.56.37 #        cya
01.56.48 #       <_Mark> bye
01.56.52 Quit    EoS ()
01.57.21 #        Linus: You know the patch for alignment in the WPS?  Is that suitable for inclusion in 2.5?
01.57.41 #        have you tried it?
01.57.42 #        wow... 3hrs and still recording
01.58.13 #        Nope.  I didn't feel that I knew enough about the WPS display code to evaluate it.
01.58.30 Part    Peuc
01.58.52 Quit    Hadaka ("leaving")
01.58.54 #        it looks simple enough, so if it works, i think it's 2.5 material
01.59.16 Join    Naked [0] (naked@naked.iki.fi)
02.00.57 #        We seem to be pretty much decided on a freeze.  Are you waiting for the chip8 patch before calling it?
02.01.20 #        i'd like that patch too, yes
02.01.30 #        and i want the tag database stable
02.01.52 Quit    jlee (Read error: 110 (Connection timed out))
02.01.53 #        Do you mean rundb?  AFAIK tagdb is stable.
02.02.36 #       <_Mark> "the chip8 patch"??
02.02.57 #        ah
02.02.59 #        chip8 plugin.  It plays old HP-48 games.
02.03.01 #        was chip8 ever fixed?
02.03.05 #        on iriver
02.03.17 #        Apparently someone has a patch.
02.03.20 #        ah
02.03.23 #       <_Mark> it works for some people
02.03.27 #       <_Mark> whats the patch do?
02.03.32 #        dunno
02.03.34 #        Fixes it.
02.03.37 #        hehe
02.03.44 #       <_Mark> it works on my ihp
02.03.44 #        That's all we know.  No-one's seen the patch yet.
02.03.46 #        iirc the main problems with display+speed issues
02.04.02 #        http://www.rockbox.org/mail/archive/rockbox-archive-2005-07/0033.shtml
02.04.06 #       <_Mark> ROFL @ waiting for a mystery patch that no-one knows what it does
02.04.46 #       <_Mark> ahhh
02.04.49 #       <_Mark> nice patch
02.05.15 #        I need to finish z
02.06.50 #        wow
02.06.56 #        you guys really cut down the amount of bug reports
02.10.34 #        this makes me sad: http://www.misticriver.net/boards/showthread.php?t=24578
02.11.26 #        LinusN: Could you look at this? http://nopaste.php-q.net/145178
02.11.39 #        i cant compile and run it at the iriver
02.11.52 #        and i dont know if it works
02.12.49 #        did you adapt the radio screen as well?
02.13.06 #        its based on this: http://lkml.org/lkml/2005/4/5/400
02.13.46 #        i think.. i must look at the other computer... but i can do this tomorrow... now i am not at home
02.15.15 #        upload what you have as a patch in the tracker, so i/we can continue working on it
02.15.26 #        ok
02.16.00 Join    ashridah [0] (ashridah@220-253-120-16.VIC.netspace.net.au)
02.18.21 #       * Cassandra thinks thoughts about mysticriver users.
02.21.12 #        You know, I'm beginning to think Rockbox on iPod would be a dreadful idea, since it would dilute the average user inteligence even further.
02.21.28 #        Cassandra: my thoughts exactly
02.21.57 #        goes in line with my "wma user with a clue" argument earlier
02.22.33 #        the guy who chooses to buy an ipod doesn't need, and will probably not appreciate rockbox
02.23.00 Quit    gromit`` (Read error: 110 (Connection timed out))
02.23.14 #        I put a lot of effort into making Rockbox comprehensible for Joe Average.  Shame a lot of them don't put in even the little bit of effort required to read the manual/faqs/whatever.
02.25.16 Join    amiconn_ [0] (~jens@p54BD6A93.dip.t-dialin.net)
02.25.18 #        are we leaving the h300 build red so that people don't ask about it?  the fix is simple
02.25.33 #        hehe, i simply don't care
02.25.58 #        heh
02.26.28 #        but you have a point
02.26.43 #        it might be better if it stayed red
02.27.40 #        I think it should stay red till the LCD driver is in place.
02.27.57 #        at least until we can boot some code
02.27.58 #        What needs fixing with tagdb, Linus?
02.28.20 #        Cassandra: i just feel like there's so much happening in that area
02.28.37 #        with both a perl and a java version of the creation tool
02.28.55 #        Wish someone'd write one in C.
02.29.14 #        and lately i have seen some "it doesn't work with the latest builds anymore" posts in the forums
02.29.31 #        I think the perl one is out of date, yes.
02.29.50 #        so we need so sort that out
02.30.41 #        It's also kind of buggy.
02.31.06 #        The java one seems OK apart from the minor problem that it's written in bloody java.
02.31.16 #        w00t austriancoder patch it's ready :)
02.31.46 #        its only a try... i cant test it.. broken iriver
02.31.55 #       * Cassandra rebuilds her Archos toolchain in preparation for looking at the alignment patch.
02.32.41 Join    gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net)
02.35.00 #        What's the patch do, austriancoder?
02.36.16 #        Customise the crossfader?  Where do people get these ideas from.
02.36.19 #        Cassandra: i2c stuff, plus fm radio
02.36.34 #        Oh, cool.  What's the i2c stuff do?
02.36.42 #        fm radio
02.36.55 #        Ah.
02.36.55 #        the fm chip speaks i2c
02.37.18 #        this patch does only i2c.. radio will follow, when i am back home
02.39.10 #        i gotta go to bed
02.39.33 #        Night.
02.40.24 #        Oh, arse.
02.40.31 #        thx
02.40.38 #        My gcc-3.3.6 build choked.
02.41.31 Quit    amiconn (Read error: 110 (Connection timed out))
02.41.32 Nick    amiconn_ is now known as amiconn (~jens@p54BD6A93.dip.t-dialin.net)
02.41.53 #        Oh, hold on.  I didn't apply the workaround.
02.42.22 Part    LinusN
02.42.29 Quit    austriancoder ("using sirc version 2.211+KSIRC/1.3.12")
02.43.10 #        time to go to sleep to here
02.43.15 #        good night all
02.43.21 #        Way past time to sleep here.
02.43.27 #        Insomnia strikes again.
02.43.31 #        :)
02.43.54 Quit    Moos (" HydraIRC -> http://www.hydrairc.com <- Go on, try it!")
03.10.34 #        4hrs and still recording
03.10.35 Quit    _Mark (Read error: 111 (Connection refused))
03.11.13 Quit    Stryke` (Read error: 60 (Operation timed out))
03.14.24 #       * Rori just watched The Matrix DeZionised. Much better.
03.14.53 Join    wladston [0] (wlad@200.139.133.172)
03.15.26 #        ppl .. anyone here worked with Z80 before??
03.15.37 Join    _Mark [0] (~fake@40-218.207-68.tampabay.res.rr.com)
03.16.11 #       <_Mark> linus, still around?
03.16.36 #        He went to bed.
03.17.28 #        i'm in lack of good disassembler ... ida does not solve the problem .. =(
03.20.26 #        Sorry, no idea.
03.23.46 #        =( ok ... thanks ...
03.28.02 Quit    xen` (Read error: 110 (Connection timed out))
03.35.08 Quit    wladston ()
03.49.05 ***     Saving seen data "./dancer.seen"
03.51.34 #        record-0.wav, 0 bytes :(
03.55.20 Join    CheeseBurgerMan [0] (~Dan@tc2-225-088.altelco.net)
04.02.04 #       <_Mark> ouch
04.02.13 #       <_Mark> how long was it going for?
04.05.51 Join    QT_ [0] (as@area51.users.madwifi)
04.19.30 Quit    QT (Read error: 110 (Connection timed out))
04.22.31 Join    jlee [0] (~jlee@69-175-94-207.frdrmd.adelphia.net)
04.23.16 #        _Mark, it was recording for over 4 hrs when the battery went down
04.26.39 Quit    tvelocity ("Leaving")
04.28.42 Quit    _Mark (Read error: 104 (Connection reset by peer))
04.33.36 Part    CheeseBurgerMan
04.38.37 Nick    Febs is now known as Febs_away (~chatzilla@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com)
04.45.28 Join    Stryke` [0] (~Chairman8@cpe-24-168-110-99.si.res.rr.com)
05.10.34 Quit    Stryke` ("Friends don't let friends listen to Anti-Flag")
05.38.26 Quit    thegeek (Read error: 104 (Connection reset by peer))
05.46.54 Quit    hardeep ("BitchX: so real, you'll wet yourself!")
05.48.29 Join    _Mark [0] (~fake@40-218.207-68.tampabay.res.rr.com)
05.49.06 ***     Saving seen data "./dancer.seen"
05.54.43 Quit    ashridah ("Leaving")
06.00.22 Quit    RotAtoR ()
06.04.08 Join    webguest32 [0] (~cb00dff3@labb.contactor.se)
06.04.11 Quit    webguest32 (Client Quit)
06.08.06 Join    Zoom2 [0] (~4108040d@labb.contactor.se)
06.22.11 Quit    Zoom2 ("CGI:IRC (EOF)")
06.39.27 Quit    jlee ("leaving")
06.47.57 Join    ashridah [0] (ashridah@220-253-120-56.VIC.netspace.net.au)
07.01.57 Quit    _Mark (Read error: 110 (Connection timed out))
07.33.09 Join    courtc_ [0] (~courtc@adsl-158-11-226.asm.bellsouth.net)
07.34.02 #        morning all
07.34.18 Quit    courtc (Connection timed out)
07.48.37 Quit    ashridah ("Leaving")
07.49.08 ***     Saving seen data "./dancer.seen"
07.53.54 Join    kaouete [0] (kkwet@vol75-8-82-233-236-81.fbx.proxad.net)
07.53.55 #        yo
07.59.52 #        if i want to change the hdd in my archos recorder 15, is it better to have one with a big cache (about 8mo) or will it just drain more power for no more performance ?
08.00.33 #        i just read a topic with the same question on the speed of the hd
08.01.52 #        because for the same price you have hd with double size and 8mo instead of 2mo, i'm wondering if it is a good idea to take one like that
08.02.17 Join    LinusN [0] (~linus@labb.contactor.se)
08.05.52 #        and another question : is the next stable rockbox (fox archos) planned to be rleased soon ? :]
08.07.38 #        kaouete: rockbox 2.5 will probably be feature-frozen in a couple of days
08.08.01 #        then expect it within 1-2 weeks
08.08.12 #        but 2.5 is only for Archos devices
08.08.29 #        ok :]
08.08.39 #        that . .. . . "rocks"
08.09.56 #        feature-frozen?
08.09.58 #        what does that mean?
08.10.16 #        only bugfixes?
08.10.27 #        there will only be bugfixes
08.10.29 #        yes
08.12.43 #        only bugfixes, but iriver development may continue
08.13.00 #        ah
08.13.02 #        :]
08.18.01 #        morning
08.18.50 #        yo
08.20.30 #        kaouete: regarding the hard drive, a large cache won't help at all
08.21.01 #        LinusN: Someone had the idea to go to 11 MHz while on USB on iriver. What do you think?
08.21.12 #        absolutely
08.22.00 #        it's a little tricky with the current solution though
08.22.09 #        LinusN: ok, thanks
08.22.10 #        especially since the backlight boosts it
08.23.26 #        Ah, yes
08.23.44 #        It boosts only while fading though...
08.24.31 #        Perhaps the base frequency could be switchable
08.25.07 #        During normal operation it would be 48 MHz (or whatever we change it to) and during USB it would be 11 MHz
08.25.43 #        Hmm, what about third boost level? So 0 would be 11 MHz, 1 48 and 2 120 MHz
08.25.58 #        It may be easier to let the fading not boost while on usb
08.26.17 #        ...or not
08.26.44 #        or disabling the cpu_boost while on usb?
08.27.32 #        something like locking the cpu to the current frequency and cpu_boost should not have any effect while it's locked
08.28.14 #        I don't think this would be good
08.28.42 #        Imagine the fading locks it at 48 MHz while playing a .flac...
08.29.08 #        no, i mean that the usb handler may lock it :)
08.30.33 #        AH
08.30.59 #        There would be some (very minor) problem with backlight fading and USB
08.31.27 #        If USB is plugged or unplugged while fading, it would glitch
08.31.44 #        I'd say this can be ignored
08.32.48 #        hmm, that's true..
08.34.12 #        i think so too, it's not very common that usb is plugged in while backlight is fading :)
08.34.22 #        i think the base frequency idea is the best one
08.35.04 #        mrf. 8 am is too early
08.35.30 #        Hmm, but then the backlight fading would still boost from 11 MHz -> 48 MHz?
08.35.38 #        no, to 120
08.35.42 #        from 11 to 120
08.35.44 #        oh..
08.36.00 #        that doesn't sound very good either.. :)
08.36.05 #        why?
08.36.32 #        because we jump to 120 when we don't need to do so.. but maybe it's quite minor problem
08.37.07 #        quite minor
08.37.33 #        not many users play with the buttons during usb transfer
08.37.46 #        and yes.. changing the base frequency would prevent glitches if the backlight is fading while plugging the usb
08.38.03 #        and it's a pretty small change in rockbox
08.41.22 #        LinusN: Any news for the MFDR(2) change?
08.41.35 #        nope
08.41.46 Join    DJ_Dooms_Day [0] (~scottr@220-245-186-182.tpgi.com.au)
08.43.25 #        amiconn: how about this:
08.44.07 #        let cpu_boost() check usb_inserted() and select CPUFREQ_DEFAULT if true and CPUFREQ_NORMAL if false
08.44.26 #        Heya
08.44.30 #        Whats news guys?
08.45.36 #        DJ_Dooms_Day: not much, just hacking along
08.45.48 #        LinusN: That would be Slasheri's locking idea, and could work, but there are 2 things to consider
08.46.14 #        yes, it needs to go back to the correct frequency when unplugging
08.46.17 #        (1) How would the transition 48MHz -> 11MHz happen? cpu_boost() might not be called
08.46.27 #        that too
08.46.31 #        Anymore big leaps made? I heard mp3 playback is now all good. But there were still a few freezing bugs out there
08.46.35 #        Same for the transition back at the end, yes
08.46.59 #        (2) You should not check usb_inserted(), but ask the internal status of the usb thread
08.47.00 #        the lame approach would be cpu_boost(true);cpu_boost(false;
08.48.01 #        amiconn: that's what usb_inserted() does, doesn't it?
08.48.05 #        DJ_Dooms_Day: Currently i don't know any bugs that can cause a crash (except resampling to too low frequency)
08.48.42 #            return usb_state == USB_INSERTED;
08.49.47 #        LinusN: Ah, yes. I confused it with usb_detect()
08.50.00 #        thoght so
08.50.12 #       * LinusN can't spell today
08.50.30 Nick    QT_ is now known as QT (as@area51.users.madwifi)
08.51.46 #        amiconn: the other approach would be to introduce a new system function, let's say cpu_idle_mode(bool yesno) or something
08.51.47 #        Slasheri - Cool, so if i put it on i could browse and listen to music just fine? Has the browsing code been completed?
08.52.01 #        Slasheri: i hear complaints about "ticking" when upsampling
08.52.34 #        Yeah i heard that too
08.52.34 #        cpu_idle_mode() sounds good, imho
08.53.05 #        Has the 'ticking' problem been fixed?
08.53.07 #        The ticking while upsampling is caused by roundoff errors
08.53.31 #        Which means what?
08.53.55 #        I had an idea how to fix it, but I didn't have the time to do it. Still busy with gfx...
08.54.18 #        amiconn: any gfx progress?
08.54.23 #        Speaking of which, has greyscale been properly implemented?
08.56.58 #        LinusN: yes, that's a known problem too..
08.57.23 #        LinusN: btw, i just calculated that CURRENT_NORMAL 80 could be more accurate for iriver
08.57.46 #        Slasheri: good, change it
08.57.59 #        ok :)
08.58.24 #        but that's only when playing 128k mp3 files..
08.58.44 #        ogg takes much more current
08.58.53 #        oh
08.59.16 #        maybe we could somehow use the cpu boost ratio to calculate accurate current
08.59.20 #        so the boost ratio might be a good measure of current consumption
08.59.22 #        :-)
08.59.25 #        yes :)
09.03.41 Join    ghostiger [0] (~ghostiger@f5764a7ca1cfeb36.session.tor)
09.04.07 #        hmm, should cpu_idle_mode have the same type of counter? i don't think it should be necessary
09.05.16 #        Hmm, where is that cpu_idle_mode?
09.05.37 #        it will be in system.c
09.05.43 #        ah :)
09.06.32 #        i mean if it should behave like cpu_boost()
09.06.35 #        LinusN: Didn't you check the logs? ;)
09.06.36 #        22.38.13 #        Hmm, 4-grey core done, screendump adapted, x11 sim (temporarily) adapted. Win32 sim and bmp2rb still left...
09.06.49 #        That was y'day
09.06.53 #        ah yes
09.07.03 #        so, how slow is it btw?
09.07.09 #        now iriver shows remaining 16h 15 min.
09.07.17 #        I don't notice a difference in the UI
09.07.44 #        goodie
09.07.44 #        It's only that the LCD is slower when actually showing greyscales
09.07.46 #        i think that's better although it's still not accurate on every type files
09.08.09 #        The screendump works very nice, producing 16-colour bmps
09.08.12 #        Slasheri: better than before at least
09.08.18 #        amiconn: kewl
09.08.23 #        (bmp only allows 1, 4, 8 and 24 bit depth)
09.08.49 #        i see
09.08.49 #        ...and I fixed the bmp header with some advanced preprocessing :)
09.09.04 #        Does the current rockbox compile have greyscale in it?
09.09.10 #        DJ_Dooms_Day: Nope
09.09.19 #        My local version has, though
09.09.33 #        heh, nice
09.10.01 #        i think i might put rockbox on my iriver
09.10.13 #        finally
09.11.18 Join    cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de)
09.12.39 #        Hmm..
09.12.56 #        Crossfade has stopped working in the latest cvs i think :/
09.13.08 #        how nice
09.13.24 #        i don't know yet why, just noticed it when i did update
09.16.53 #        Gapless is still not smooth with lame --nogap encodings
09.17.18 #        These should be the easiest imho, but for some reason some frames are still dropped
09.25.10 Quit    Seed (Read error: 104 (Connection reset by peer))
09.26.21 #        fixed, there was a problem that crossfade_init was called twice
09.26.41 Join    B4gder [0] (~dast@static-213-115-255-230.sme.bredbandsbolaget.se)
09.37.57 Quit    ghostiger (Remote closed the connection)
09.40.00 Join    Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il)
09.41.57 #        https://sourceforge.net/tracker/?func=detail&atid=439120&aid=1232549&group_id=4
09.41.57 #        4306
09.42.14 #        anyone here checked it out?
09.49.12 ***     Saving seen data "./dancer.seen"
09.49.34 #        erm, i've got a question
09.50.03 #        when in the WPS, if we push one button, we have the file list, how do we go back to the WPS ?
09.50.21 #        the play button
09.50.32 #        (on iriver)
09.50.52 #        hum
09.50.54 #        ok
09.51.03 #        but this won't play the highlighted file?
09.51.10 #        no
09.51.23 #        ok
09.51.25 #        thx
09.51.25 #        ^^
09.55.21 #        Maxime: not very intuitive, i know
09.56.08 #        http://www.rockbox.org/twiki/bin/view/Main/DynamicCPUFrequency
09.56.33 #        LinusN: i've looked as with the original firmware so.. I've thought play started the selected file so.. lol ^^
09.56.58 #        one *could* expect that Play plays a file... :-)
09.57.18 #        yep that's why.. lol
09.57.24 #        we might change that behaviour as the iriver version matures
09.57.30 #        hmm
09.57.40 #        really need to stick with a naming convention
09.57.46 #        why not cpu_boost_mode() or cpu_idle() ?
09.57.46 #        :p
09.59.04 Quit    Seed (Read error: 104 (Connection reset by peer))
09.59.06 #        cpu_boost() is more of a request to boost the cpu
09.59.23 #        is idle not also a request?
09.59.25 #        cpu_idle_mode is a mode change
09.59.40 #        hmm, ok
09.59.41 #        that affects the cpu_boost() behaviour
09.59.50 Join    Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il)
09.59.56 #        is it normal that a 22Khz mp3 is playing -slowly- ?
09.59.59 #        i think so
10.00.00 #        no?
10.00.12 Nick    Lynx_awy is now known as Lynx_ (~lynx@tina-10-4.genetik.uni-koeln.de)
10.00.16 #        Maxime: no, that's not normal
10.00.22 #        ah..
10.00.24 #        lol
10.00.35 #        is it stereo or mono?
10.01.18 #        I think the tag is'nt well done, rockbox detects it as a 22Kz, winamp as a 44
10.01.48 #        my guess, send it to one of the codec devs
10.01.57 #        (the mp3)
10.02.11 #        Maxime: put it up somewhere so we can dl it
10.02.19 #        i'll try with the latest cvs version first
10.02.23 #        :)
10.03.31 #        Rick: do you have a suggestion to make the boost api clearer?
10.03.50 #        LinusN: not really
10.03.55 #        or to explain it better in the wiki?
10.04.34 #        well, it sounds like something that would conflict with each other (boost() then setting idle mode)
10.04.53 #        hmmm, yes
10.05.31 #        also
10.05.36 #        is it possible to get the current state?
10.06.12 #        not officially :-)
10.06.20 #        do you think it's needed?
10.06.40 #        mm, dunno, just a random thought that popped into my head
10.06.56 #        what's happens if we ask two times cpu_boost(true) ?
10.07.02 #        I guess the boost tracking would take care of it
10.07.12 #        (assuming it removes the boost afterwards)
10.07.40 #        Maxime: it will boost as usual, but it won't unboost until cpu_boost(false) is called twice
10.07.54 #        erm ok
10.08.48 #        so if cpu_boost(true) is called four times, to unboost you have to call cpu_boost(false) four times.. maybe a verification might be "useful" .. or no.. lol
10.08.57 Join    markun [0] (~markun@bastards.student.ipv6.utwente.nl)
10.09.19 #        LinusN: does iriver have some sort of 'timeout' for unboosting?
10.09.25 #        er
10.09.27 #        not iriver
10.09.28 #        rockbox
10.09.30 #        nope
10.09.43 #       * Rick shrusg
10.09.58 #        rockboy wouldn't appreciate that
10.10.02 #        hehe
10.10.45 #        Did rockboy ever get the key sequence stuff yet?
10.10.54 #       * Rick hasn't been keeping up with development
10.11.04 #        key sequence?
10.11.11 #        yes
10.11.14 #        it was a feature I suggested
10.11.27 #        for repeating key presses at the same time so you can simulate having extra keys
10.13.06 #        basically the idea was that you register a key sequence using play (hold play, press first key, then second key) then the first key would be bound to simulate those keys being pressed at the same time
10.14.01 #        wee, would be hard to play sonic that way :-)
10.14.09 #        the mp3 is detected as a "mp2 22050Hz, 48Kbps CBR"
10.14.25 #       * LinusN realizes that sonic is a Sega game :-)
10.15.00 #        Maxime: can i see the file?
10.15.09 #        yup
10.15.17 #        I'll upload it, gimme a sec
10.15.36 #       * LinusN thinks the vorbis seek patch looks ok
10.16.28 #        LinusN: howso?
10.17.10 #        LinusN: http://maxime67.free.fr/slow/raoul.mp3 <
10.17.30 Join    MisticJeff [0] (~41ad57d4@labb.contactor.se)
10.17.43 #        Howdy
10.17.46 #        yo
10.18.03 #        LinusN: all Rockbox FAQs removed from MisticRiver
10.18.15 #        MisticJeff: sorry for being grumpy
10.24.27 #        i have a nice debugging idea, a good project for the iriver wannabe hacker
10.24.57 #        i want a cpu frequency field in the iriver status bar
10.25.18 #        iriver has a status bar?
10.25.18 #        :o
10.25.24 #        good to have during development
10.25.32 #        oh
10.25.34 #        you mean that top bar thing?
10.25.37 #        yes
10.25.40 #        hehe
10.25.54 #        We call it "the status bar". ;)
10.26.01 #        should be a pretty simple hack in status.c
10.26.46 #        dunno
10.26.55 #        in about a month i'll probably start working on z again
10.26.59 #        in preperation for college ;P
10.27.10 #        round up FREQ to MHz, snprintf() it to a buffer and put it in the status bar
10.28.45 #        wee, ogg seeking works, and vorbis comments too
10.28.56 #        cool :)
10.29.39 #        oh, when that has started working?
10.29.49 #        a patch came in this morning
10.29.56 #        great :)
10.29.57 #        i'm just about to commit it
10.29.58 #        a mystical magic patch that is
10.29.59 #        :)
10.30.16 #        The Magical Mystery Patch
10.30.28 #        haha
10.39.57 Join    leftright [0] (~d4406110@labb.contactor.se)
10.40.00 #        i'm getting negative playtime in wps
10.40.10 #        cool lol
10.40.24 #        ah, may rockbox show the remaining time instead of elapsed,
10.40.25 #        yes me too, whenever I pley the last track in a file only
10.40.32 Join    Godeater [0] (~c2cbc9d1@labb.contactor.se)
10.40.33 #        pley=play
10.40.56 #        Maxime: I've added your problematic song to my collection
10.41.06 #        k ^^
10.41.19 #        http://daniel.haxx.se/rockbox/probbs/
10.41.30 #        it seems to occur after skipping
10.41.35 #        to the next file
10.44.35 #        I get negative time display and the file playback stalls at 00:-4, this inly occurs if I select the last track in a file for playback
10.44.37 #        vorbis seeking and comment support committed, thanks to Ryan Jackson
10.48.48 Join    Aison [0] (~hans@zux166-181.adsl.green.ch)
10.49.54 Join    ashridah [0] (ashridah@220-253-120-151.VIC.netspace.net.au)
10.51.42 #        HCl: when will we get that java parser thing in CVS?
11.01.58 #        lunch time
11.03.09 Quit    Seed (Read error: 131 (Connection reset by peer))
11.08.44 Join    Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il)
11.11.17 Quit    Seed (Read error: 54 (Connection reset by peer))
11.11.44 Nick    Naked is now known as Hadaka (naked@naked.iki.fi)
11.15.08 Join    Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il)
11.23.04 Join    niobos [0] (~niels@89.2-136-217.adsl.skynet.be)
11.23.12 #        morning all
11.23.20 #        lunch!
11.23.28 #        hmm... whatever
11.24.05 #        i've just finished my exams, so I decided I could sleep until lunch...
11.25.33 #       * niobos is off to breakfast... or lunch...
11.28.29 Quit    Godeater ("CGI:IRC (EOF)")
11.37.55 #        can someone guide a noob through getting the tag database up and running using the .jar file?
11.38.52 #        copy to root>from DOS run java -jar d:\songdb.jar d:\  and absolutely nothing happens
11.40.29 #        HCl is the pro, its his baby
11.42.01 Join    ep0ch [0] (user@146.99-84-212.ippool.ndo.com)
11.48.15 Part    MisticJeff
11.48.47 Join    [-AIR-] [0] (air@host86-130-24-50.range86-130.btcentralplus.com)
11.48.51 Nick    [-AIR-] is now known as west-acre (air@host86-130-24-50.range86-130.btcentralplus.com)
11.48.55 #        hey
11.49.13 ***     Saving seen data "./dancer.seen"
12.13.40 Nick    Febs_away is now known as Febs (~chatzilla@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com)
12.13.57 Quit    ep0ch (Read error: 60 (Operation timed out))
12.18.52 Join    Moos [0] (MoosCamaro@m214.net81-66-158.noos.fr)
12.20.31 Join    hicks [0] (~hicks@zeus.mups.co.uk)
12.25.25 Quit    Maxime (Read error: 104 (Connection reset by peer))
12.27.45 Quit    DJ_Dooms_Day (Read error: 104 (Connection reset by peer))
12.32.02 Join    Maxime [0] (~flemmard@fbx.flemmard.net)
12.53.06 Join    rwlogix [0] (chat@brunhilde.unixload.de)
12.53.11 #        moin
12.54.13 #        afternoon
13.04.38 #       * B4gder takes the plunge
13.04.47 #        into 2.6.13-rc1
13.09.15 Join    thegeek [0] (na@ti521110a080-2228.bb.online.no)
13.10.11 #       * HCl encountered several crashes while using rockbox today...
13.10.18 #        also some bugs in runtime database, will look at it later
13.10.19 #       * rwlogix tries out his new "Venini"-Pipe ,)
13.10.23 #       * HCl goes to sleep x.x
13.10.47 #        good night, sleep tight
13.10.52 #        good night, sleep tight
13.22.31 #        he it's not the night in Netherlands, no?
13.23.06 #        you never know with those dutch guys ;-)
13.23.22 #        :-)
13.24.08 #        HCl: I remember there is a bug in your java database creator. It fails if the destination file doesn't exist, but works if you supply it an emty file to work with
13.24.44 #        we want the java code in CVS
13.25.04 #        or at least access to the source code
13.25.13 #        iirc the code is in the .jar file
13.25.27 #        so you can take it out from the .jar in the wiki
13.25.35 #        will do!
13.25.50 #        HCl: Btw, sorry that my init move broke the runtime db. No wonder my runtimedb didn't get populated...
13.27.07 #        so how do I extract the source code from it?
13.27.14 #        I thought jar used tar format?
13.27.21 #        .jar is .zip
13.27.25 #        aha
13.27.35 #        thanks
13.29.30 #        92 .java files !!
13.29.50 #        wow :)
13.30.21 #        and 312 .class files
13.30.33 #        WOW
13.31.12 #        lots of .class files without souce
13.34.17 #        no docs, no mention how to build it, no license texts
13.34.40 #        :(
13.34.51 #        B4gder : license : as is 
13.34.55 #        ;)
13.34.59 #        I doubt that
13.35.06 #        I think he has "borrowed" quite some code in there
13.35.55 #        anyway, i think that we need something else for future for db creation
13.36.08 #        Bagder: put the .jar in your player and java -jar SongDB.jar / for creat DB, scuse i'm not java user it was Cassandra and HCl who helped me
13.36.35 #        Moos : he knows how to use it, he wants the source code...
13.36.44 #        a ok
13.37.56 #        Bger: I'm working on a C-version
13.38.20 #        but with the exams I didn't do much
13.38.21 #        working on the target ?
13.38.42 #        just a C-version to create the DB
13.38.50 #        not rea/y on the target
13.38.58 #        but it might work too
13.39.28 #        it can write the DB
13.39.37 #        but doesn't sort yet
13.39.45 #        and doesn't read tags yet
13.40.41 #        It should work on the device, since it's able to store the arrays in file instead of in-mem if malloc() fails
13.41.21 #        I'll continue the dev once I'm back from vacation
13.41.31 #        i.e. in 3.5 weeks...
13.41.46 #        yeah;)
13.41.52 #        sounds good
13.41.56 #        the more the merries
13.41.59 #        merrier
13.42.15 #        I might put the current version online, in the mean time
13.42.33 #        perhaps we should put it in CVS, to allow others to join in 
13.42.35 #        i just was to suggest it
13.42.50 #        ok for me...
13.43.22 #        it would be neat to re-use rockbox code for meta tags reading for that
13.43.31 #        since that is C
13.43.58 #        I was planning to do that, but haven't had the time to reod the rb-code
13.44.23 #        s/reod/read/
13.49.15 ***     Saving seen data "./dancer.seen"
13.50.46 #       * niobos is off to lunch
13.51.03 #        let me know what to do for CVS
13.55.44 Join    bipak [0] (~bip@p508867E3.dip.t-dialin.net)
14.13.13 Quit    bipak_ (Read error: 110 (Connection timed out))
14.21.49 Join    Maxime`Mrn [0] (~flemmard@fbx.flemmard.net)
14.21.49 Quit    Maxime (Read error: 104 (Connection reset by peer))
14.23.43 Join    RotAtoR [0] (~e@dhcp54-47.calvin.edu)
14.27.48 #        niobos: its actually up to you, since your the guy with the code!
14.28.06 #        we could add it to cvs and hand you cvs commit access to allow you and others to work on it
14.43.40 Join    Yokalosh [0] (~3efec181@labb.contactor.se)
14.44.10 Quit    Yokalosh (Client Quit)
14.50.30 #        amiconn: its fine, i hadn't documented it
14.50.44 #       * HCl goes back to sleep
14.57.27 Nick    courtc_ is now known as courtc (~courtc@adsl-158-11-226.asm.bellsouth.net)
15.10.23 Join    webguest50 [0] (~c2cbc9d1@labb.contactor.se)
15.12.54 Quit    Febs (Read error: 110 (Connection timed out))
15.13.31 Join    E-P [0] (E-P@212.30.5.140)
15.14.22 Quit    E-P (Remote closed the connection)
15.16.27 #        B4gder: ok with me. I guess I need a sourceforge account?
15.17.05 #        nope, we host the cvs repo ourselves
15.17.11 #        k
15.17.37 #        what do you need then?
15.17.42 #        I need your full name, user name and a password in a /msg
15.18.19 #        can I change my passwd later?
15.18.36 #        yes, but only via humans
15.18.42 #        k
15.18.54 #        me, zagor or LinusN
15.19.17 Join    Febs [0] (~chatzilla@64-190-36-240.client.cypresscom.net)
15.19.59 #       * amiconn now knows how to handle different dpeths in the win32 sim, and how to add grayscale lib support :)
15.20.11 #        nice
15.20.40 #        Something to do for this evening...
15.21.04 #        Grayscale lib support will come later, but it will be prepared.
15.21.39 #        Remote LCD support shouldn't be hard as well
15.22.57 #        hey amiconn
15.23.01 #        wot IS grayscale?
15.23.07 #        niobos: this code is meant for both host and target then in the end, right?
15.23.10 #        i never really figured it out
15.23.16 #        in the end, yes
15.23.17 #        does it just show what colours the LCD can use?
15.23.32 #        currently only host is tested
15.24.00 #        niobos: then I suggest making a new dir in apps
15.24.22 #        using a clever name
15.24.25 #        hm
15.24.29 #        any suggestions anyone?
15.24.40 #        nope
15.24.49 #        hmm. google earth images of my place are surprisingly recent
15.25.14 #        songdb?
15.25.16 #        I guess 'tagdb' would be a reasonable name
15.25.21 #        or songdb yes
15.25.38 #        that's what HCl called his Java-thing
15.25.50 #        I was just thinking how to avoid confusions
15.25.59 #        with the perl version, the java version and now this C version
15.26.33 #        np
15.26.41 Quit    lostlogic (Client Quit)
15.27.27 #        go with songdb, that might in fact reduce confusion
15.28.05 #        your cvs uses pserver, I guess? or ssh?
15.28.12 #        plain pserver
15.30.14 #        so I'll commit it to apps/songdb
15.30.21 #        I don't know whether apps/songdb is suitable. For the host version, it should reside in tools/ and the target version will most likely be (archos: has to be) a plugin
15.30.32 #       * niobos is off... his girlfriend just arrived
15.30.49 #        we currently have no code that is for both host and target, do we?
15.31.02 #        I would assume that we make a sort of lib
15.31.05 #        No
15.31.12 #        so that a target version is a plugin using that lib
15.32.41 #        Our dir structure is not really prepared for host & target shared code
15.33.04 #        B4gder i don't think *song*db is the best name....
15.33.42 #        it is a songdb
15.33.48 #        well, make up your minds and msg me the result
15.33.58 #       * niobos is off
15.34.06 #        with the runtimedb, it even contains songs totally without tags
15.34.28 #        or rather _for_ the runtimedb purpose
15.34.30 #        B4gder some peoples are using their jukeboxes not only for songs
15.34.41 #        yes, but this db is for songs
15.35.08 #        I think of it as the tagdb myself.
15.35.10 #        or can you forsee other uses?
15.35.37 #        audiobooks
15.35.38 #        :)
15.35.43 #        true
15.35.47 #        those aren't songs
15.35.57 #        but you can tag them as well
15.36.15 #        ok, so perhaps tagdb is the better name
15.36.45 #        at least i think so
15.37.14 #        and regarding the path, I think it is better to get it in now and possibly move it later
15.40.30 Quit    leftright ("CGI:IRC (Ping timeout)")
15.49.18 ***     Saving seen data "./dancer.seen"
15.50.52 #        I spotted a bug in the iRiver resume code.  If you let a playlist run to the end, rather than clearing the resume point, it gets set to the beginning of the last track in the playlist.
15.56.36 Quit    webguest50 ("CGI:IRC")
15.59.22 Join    webguest00 [0] (~51e6b240@labb.contactor.se)
16.00.32 #        as i can see an the daily builds the iriver h300 SIM has no errors, can i run rockbopx on my iriver h300 now ?:;D
16.00.52 #        the sim is a sim
16.01.06 #        and it simulates the wrong lcd too
16.01.54 #        but the other one only havev 4 errors ?
16.01.58 #        yes
16.01.59 #        can i use that ?:D
16.02.08 #        yes, once you've installed the bootloader
16.02.14 #        and fixed the missing lcd and adc code
16.02.17 #        is it safe :D?
16.02.24 #        what is?
16.02.28 #        there is no bootloader yet
16.02.53 #        so it is safe ;-)
16.03.39 #        aaa when does the bootloader comes out?
16.04.03 #        when someone has written it
16.04.16 #        that someone is likely to be LinusN
16.04.30 #        and no, we don't have any schedule
16.04.41 #        ;)
16.05.21 #        but to make a bootloader wont take long?
16.05.28 #        it won't?
16.06.20 #        feel free to write it
16.08.03 #        in not so good at such things;)
16.11.10 Quit    Maxime`Mrn ()
16.12.00 Quit    webguest00 ("CGI:IRC")
16.17.45 #        Hmm, does ata_spin() spin up the disk?
16.19.13 #        Iirc ata_spin() just resets the spindown timer, to keep it spinning. There is no separate spinup function.
16.19.54 #        Ah, ok. I just would like to spin up the drive before initiating a track change
16.20.06 #        Why that?
16.20.28 #        to prevent audio buffer going empty (required for crossfade to work well)
16.20.28 #        We don't want to spin up at each track change...
16.20.47 #        no, only when it's necessary :)
16.21.03 #        Slasheri: should use instead use the spinup time to caclulate when you should start reading data
16.21.07 #        ...we only want to spin up when the buffer goes empty, and that's what the low watermark is for
16.21.25 #        The low watermark is calculated dynamically on archos
16.21.29 #        amiconn: yes, of course that's not a problem
16.21.52 #        so what is?
16.22.06 #        but if user selects a new track, we want the hard disk to be ready before stopping codec and flushing old track entries
16.22.47 #        Why that?
16.22.48 #        I don't understand
16.23.03 #        this works perfectly well on archos, I don't see any new need here
16.23.06 #        that guarantees that crossfade can work.. :)
16.23.19 #        no other reason for this
16.23.26 #        I wouldn't expect a crossfade when selecting a new track, even with crossfade enabled
16.23.35 #        crossfade just increase the low watermark requirements
16.23.55 #        I like crossfade but not for next
16.24.34 #       * amiconn would *very much*prefer a correctly working gapless over any fading
16.24.46 #        i agree
16.24.56 #        i almost never use randomized playlists
16.25.48 #        The strange thing is that mp3s with a lame tag containing gapless info work, while mp3s encoded with lame --nogap (which should be the easier case imho) don't
16.26.27 #        I thought that LAME --nogap was never properly implemented.
16.26.43 #        I remember reading something about that at Hydrogen Audio recently.
16.26.49 #        I'll see if I can find it.
16.26.57 #       * LinusN runs the a-b patch on archos
16.27.03 #        lame --nogap is working perfectly if it is used correctly
16.27.18 #        a few visual glitches
16.27.44 #        lame --longhelp tells everything
16.28.07 #        I have some mix albums encoded that way, and they play perfectly gapless on archos
16.28.23 #        ...but iriver rockbox doesn't manage it
16.28.38 #        There is no added gap, but instead some frames are swallowed
16.29.06 Join    webguest88 [0] (~d4406110@labb.contactor.se)
16.30.05 #        I find that with crossfade disabled it still merges the tracks, which i dislike, its nice to have the pauses between tracks
16.30.05 #        gotta go
16.30.22 Part    LinusN
16.31.19 Quit    RotAtoR (Read error: 131 (Connection reset by peer))
16.31.28 #        Coincidentally, I'm listening to Dark Side of the Moon right now.  The transition from Breathe to Time produced a small but audible pop.  The transition from Time to Great Gig in the Sky was perfect.
16.31.28 #        unless the album is supposed to be gapless (Dark Side Of The Moon), 
16.32.06 #        This is a HUGE improvement from the iriver firmware, for which I and many others are grateful, even if it isn't yet perfectly implemented.
16.32.13 #        webguest88: Rockbox doesn't change the tracks, i.e. doesn't remove gaps that are present *in the file*
16.32.32 #        it does with crossafade off
16.32.37 #        no
16.32.44 #        it just doesn't add any gap
16.33.07 #        However, adding gaps that aren't present in the files (like the iriver fw does, always) would be evil
16.33.13 #        the songs in the playlists dont have the 'natural gaps'
16.33.40 #        but its ok I'll get a new set of ears at best buy
16.33.43 #        amiconn: uh, i thought it had silence detection and removal
16.33.43 Quit    ashridah (Remote closed the connection)
16.35.14 #        silence detection and removal would be another feature I'd deactivate immediately (like fade in/out/cross and whatever audio fading there might be)
16.36.54 Join    ashridah [0] (ashridah@220-253-120-151.VIC.netspace.net.au)
16.39.01 Join    t0mas [0] (~Tomas@ip503c08d1.speed.planet.nl)
16.39.22 #        lo
16.39.24 #       * t0mas is back :)
16.39.30 #        at last!
16.50.22 #        omg...
16.50.31 #        847 new messages
16.50.50 #        and I haven't transferred all backup MX mail
16.58.05 #        pfew...
16.58.19 #        all outgoing warning mails removed :)
16.59.03 #        awk rules the world
16.59.03 #        postqueue -p | grep "MAILER-DAEMON" | awk '{print $1}' | xargs -n 1 postsuper -d
16.59.18 #        and all warning mails are gone :)
17.00.28 Join    RotAtoR [0] (~e@dhcp54-47.calvin.edu)
17.01.01 Join    Maxime [0] (~flemmard@fbx.flemmard.net)
17.02.13 #        hello
17.02.14 Quit    B4gder ("go go go")
17.06.55 #       * HCl wonders if he found his bug..
17.07.20 Join    thegeek_ [0] (na@ti521110a080-5315.bb.online.no)
17.08.39 Join    _Mark [0] (~fake@40-218.207-68.tampabay.res.rr.com)
17.09.03 #       <_Mark> was the evil crashbug of doom in the iriver vu meter code fixed yet?
17.09.17 #       <_Mark> me wantses my precious vu meter!
17.10.18 #       * ashridah hands _Mark a text editor and  a compiler
17.10.19 #        have fun :)
17.10.31 #       <_Mark> its not MY crashbug :P
17.12.11 #       * HCl goes to fix the database generator..
17.12.14 #        hm.
17.12.20 #        or should i fix the rockbox code
17.12.44 #        ashridah: what do you think, should the fileentries be sorted case sensitive or case insensitive?
17.12.53 #        ah nm.
17.13.05 #        _Mark: you can fix someone else's bug too :P
17.13.40 #       <_Mark> i dont know C
17.14.19 #        HCl: What's the problem?
17.14.35 #        binary search failing for lowercase directory names
17.14.52 #        just altered the generator to sort it case insensitive, since rockbox' binary search assumes case insensitive sort
17.15.20 #        Yes, case insensitive is preferable imho
17.15.23 Quit    webguest88 ("CGI:IRC")
17.15.28 #        yea, since fat doesn't make a difference
17.15.48 #        pretty important bug
17.15.57 #        Imho it always makes more sense than case sensitive
17.16.00 #       * HCl fixes
17.16.01 #        yea
17.16.21 #        insensitive gets my vote
17.16.24 #        (perhaps except for some system dirs on *nix)
17.16.34 #        i dunno how the perl version handles it at the moment..
17.18.12 #       * HCl uploads a new songdb.jar to the wiki..
17.18.40 #        does anybody happen to know about crash bugs while playing solitaire while playing music?
17.19.55 #        thats the first critical bug in the java generator, i think :)
17.20.18 #       <_Mark> anyone noticed that all the newbs submitting iriver wps's are overwriting each other's because theyre all called dump_001.bmp and theyre morons?
17.20.29 #        nope.
17.20.33 #       <_Mark> and fecking stupid opera cant render bmps in webpages
17.20.49 #        but i did see that using the same name twice in the wpsgallery ended up in bad wiki links
17.21.48 #        _Mark: The 'overwritten' files aren't lost. Twiki does automatic versioning, so they should be still available.
17.22.13 #        also, what would be a better way to hash files? take the 32kb in the middle of the file?
17.23.31 Quit    thegeek (Read error: 110 (Connection timed out))
17.23.57 #        HCl: Did you fix the songdb bug that it doesn't work if the database file doesn't exist?
17.24.11 #        not yet, let me take a look at that
17.24.37 #        ah hrm.
17.26.18 #       * HCl prods java and scratches his head
17.28.46 #        bleh, i wonder why i can't find an canCreate() function, but i'll code around it.
17.31.29 #        ah.
17.31.35 #        it does, but by the means of an ioexception
17.32.21 Quit    ashridah ("sleep")
17.32.34 #        java - it's evil
17.32.57 #        naw.
17.33.24 #        amiconn: will you be able to give the version i'm about to upload a testrun with some bad directory permissions?
17.34.04 #        Hmm?
17.34.17 #        trying to create a database in a non writable directory and such
17.34.25 #        i don't have java on a linux machine at the moment..
17.34.40 #        I'm not running Linux, and I'm always running the generator on the unit == FAT32
17.34.43 #        k
17.34.49 #        Cassandra?
17.34.53 #        can you commit this one: http://sourceforge.net/tracker/index.php?func=detail&atid=439120&group_id=44306&aid=1231281
17.35.00 #        or have you got any open bugs?
17.35.01 #        I'm not sure whether my Linux VW contains a java installation
17.35.03 #        yea, well, linux has mounted fat32 readonly before.. but i'll search for someone else..
17.35.10 #        probably not
17.35.11 #        s/VW/VM/
17.35.46 #        but yea
17.35.47 #        bug fixed
17.35.52 #        t0mas: Just not got around to testing yet.
17.35.58 #        Expect a commit later today.
17.36.42 #        ok
17.36.46 #        does anyone know why my iriver doesn't seem to store the wps file its supposed to use? everytime i boot it its set back to default
17.36.55 #        Cassandra: i've read it (not tested) looks ok to me
17.37.02 #        I prefer making sure I understand patches before I apply them, which in this case was a good idea, since I spotted a bit of cruft code that shouldn't have been in the patch.
17.37.07 #        maybe check why he wants us to put %s before and not after it
17.37.33 #        HCl:  Storing it in /.rockbox/ ?
17.37.52 #        nope, i was just about to move it there to see if that helps
17.37.54 #        is it required?
17.37.55 #        t0mas: From my reading of the code, that ought not to matter.  I'll test it.
17.38.13 #        Rockbox only remembers wps settings if they're in there.
17.38.34 #        t0mas: did you read my proposed simple-graphics wps tags thing?
17.38.36 #        HCl: Yes, for storing it permanently
17.38.40 #        amiconn: k
17.39.04 #        Rockbox stores the name only, without path
17.39.19 #        ah.
17.39.22 #        There isn't much space in the config sector
17.39.24 #        Cassandra: that was what I read there too...
17.39.25 #        so i can't do .rockbox\wps\new.wps either
17.39.44 #        Cassandra: but still... he writes it should be before... so I wonder why he did that
17.39.52 #        HCl: no, where is it?
17.40.14 #        t0mas: well, irc logs, but my suggestion was to have a few simple graphic tags like draw line from x,y to x,y
17.40.21 #        so we stop forcing people to resort to ascii art
17.40.29 #        think it would be possible?
17.40.31 #        HCl: that should be easy...
17.40.37 #        i think it would help tons
17.40.42 #        with how the wps looks for people
17.40.45 #        just add 1 virtual image... and paint the things on that
17.40.56 #        but... people can add those lines to a bmp too...
17.41.18 #        yea, but its less work with just a line tag for simple seperator lines and stuff like that..
17.41.21 #        right?
17.41.43 #        its just cause i was looking at the wps gallery and noticed a lot of people were resorting to ascii art
17.41.58 #        The ascii art is pre-bitmap-wps
17.42.05 #        yea, i guess thats true
17.42.18 #        ah well, it was just a suggestion :)
17.42.26 #        it shouldn't be difficult
17.42.37 #       * amiconn wonders what'll happen to bitmap wps when he commits 4-grey graphics core
17.42.37 #        I actually have a BDF font that contains CP437 line graphics.
17.42.40 #        do you think you might have some time to add it?
17.42.44 #        amiconn, there are already line painting functions on your gfx lib right?
17.42.55 #        Unfortunately, it doesn't seem to work in Rockbox, and I have no idea why.
17.43.17 #        amiconn: I'll update bmp loading code for grayscale... and some people will start using weird backgrounds and stuff like that
17.44.28 #        heheh.
17.44.57 #        does anyone have any suggestions on what to hash?
17.45.23 #        Don't hash the middle.  It'll really screw up with "hidden" tracks.
17.45.27 #        i need to improve the hashing algorhythm before everyone uses the current hash extensively
17.46.09 #        Imho the best solution would be to hash the beginning, but after the tags
17.46.28 #        hash the id3 info and the first n seconds of non-silence (volume > delta).
17.46.42 #        amiconn: yea, but how would i do that?
17.46.55 #        However, that would require some more sophisticated parsing, might be undesirable on target
17.47.02 #        Do we need to hash on target?
17.47.08 #        Cassandra: i was wanting to not hash the tags cause then files with different tags but the same song will still get registered as the same file
17.47.18 #        amiconn: at the moment, no. but that might change in the future
17.47.20 #        amicon: I think it's desirable.
17.47.31 #        but even then we'd have an option to hash on target or not
17.47.37 #        HCl: Hence the reason why you hash the tags and part of the tune.
17.47.46 #        eh?
17.48.00 #        maybe i don't understand what you mean..
17.48.04 #        Cassandra: The reason for my suggestion is to *not* hash on the tags
17.48.08 #        you mean 2 hashes Cassandra?
17.48.14 #        or you're talking bs :P
17.48.34 #        The tags might change, but the track is still the same
17.48.37 Join    fogcat [0] (~c2489e63@labb.contactor.se)
17.48.41 #        yea
17.48.43 #        exactly
17.48.48 #        i already had that occur on my player..
17.48.55 #        t0mas: No, it's all data.  You can treat the info structure + a section of track as a single block of data for hashing purposes.
17.49.15 #        Cassandra: yes, but then you didn't understand the reason why HCl doesn't want to hash the tags
17.49.20 ***     Saving seen data "./dancer.seen"
17.49.47 #        can I ask a question about that alignment patch? 
17.49.54 #        Does it allow different alignments on the same line i.e. one bit of info aligned left and one aligned right?
17.50.04 #        Oh, right.
17.50.07 #        Cassandra: I think it is desirable to find duplicates which only differ in tagging
17.50.15 #        fogcat: it doesn't
17.50.16 #        shall i just hash the middle 32kb of a song?
17.50.21 #        I agree with amicon.
17.50.31 #        we all do Cassandra 
17.50.34 #        ok - but I bet that's what is asked for nexy ;-)
17.50.35 #        but we want a way to do that
17.50.42 #        HCl: No.  Think of tracks from the end of a CD with a "hidden extra" on.
17.50.48 #        HCl: The middle wouldn't help in finding duplicates with different tags
17.50.54 #        HCl: They'll have silence in the "middle"
17.51.01 #        hrm.
17.51.01 #        The tags might change in length
17.51.03 #        fogcat: and I bet it's something I'll code if noone does it before the end of my vacation
17.51.09 #        what should i do then ? :/
17.51.16 #        i don't quite know how to parse tags
17.51.26 #        and i doubt my backend provides info about it
17.51.46 #        Rockbox already includes tag parsing code
17.51.59 #        Too bad it's C and your songdb is java :P
17.52.01 #        what about ape and stuff like that?
17.52.06 #        omg
17.52.11 #        LOL
17.52.14 #        m?
17.52.16 #        cheers - nice one t0mas, I really should see if I can set up a build environment and remember C - talking here makes me feel guilty
17.52.20 #        just pumped about 1700 emails to my isp
17.52.24 #        I have quite a few instances of two identical songs with differing tags.
17.52.28 #        don't thing they liked it :P
17.52.39 #        I think it would annoy me to have them treated as the same.
17.52.39 Quit    _Mark (Read error: 111 (Connection refused))
17.52.51 #        Or maybe it wouldn't.  I'm confusing myself now.
17.52.54 #        fogcat: yes, that's the way I started here too ;)
17.53.07 #        the only way in which they'd be treated the same is filerating, playcount, and stuff like that
17.53.25 #        Cassandra: Why do you do that? I can't think of a reason...
17.53.47 #        hm...
17.53.58 #        HCl.. what about the last part of a song?
17.54.02 #        sure
17.54.06 #        shall i just do that?
17.54.10 #        but not 32 kb
17.54.10 #        but wait
17.54.11 #        ami:  If I have a track on a greatest hits album.  Say "Hey You" which I have on both "Echoes" and "The Wall" (and a third, different version on "Is there anybody out there?")
17.54.14 #        it might be silence...
17.54.16 #        i should like
17.54.17 #        hm
17.54.18 #        do a bit more..
17.54.19 #        no wait.
17.54.33 #        t0mas: the more i hash, the longer it takes to generate a database..
17.54.49 #        HCl: yes, but 32 kb is not much...
17.54.56 #        320 kbits = 40 kb/s
17.55.04 #        mhm..
17.55.07 #        I think you should parse the MP3 until you find the first 32kb where vol>delta
17.55.15 #        so... the last 1 second can be silence... and you'll hash a lot of files the same
17.55.15 #        but they're not all mp3
17.55.22 #        and we want to support future formats like wavpack too
17.55.30 #        t0mas: yea, exactly
17.55.30 #        Ah, yeah.  :(
17.55.56 #        what was there against hashing the middle of a file again?
17.56.07 #        Hidden tracks on albums.
17.56.08 Join    Strath [0] (~mike@dgvlwinas01pool0-a237.wi.tds.net)
17.56.09 #        Cassandra: I don't think tracks will ever be identical if they're encoded from different albums
17.56.34 #        i don't quite understand that... what happens with hidden tracks?
17.56.58 #        Last track is followed by a couple of mins silence then the "hidden track".
17.57.05 #        ah..
17.57.09 #        well
17.57.17 #        if the cd was ripped properly, wouldn't the hidden track have its own file
17.57.17 #        ?
17.57.18 #        It's a stupid idea, but we're stuck with it.
17.57.33 #        No, because it's all on the last physical track of the CD.
17.57.53 #        hrm
17.57.55 #        I can think of at least 4 albums I have that do this.
17.57.59 #        I also have one such album... with 3 bonus tracks all appended to the last listed track
17.58.10 #        The musicbrainz people hash music files - is it worth checking out how they do it?
17.58.14 #        i don't like those albums x.x heh.
17.58.23 #        ...and ~2.5 minutes silence before the first bonus track
17.58.38 #        Total track length is 22 mins
17.58.51 #        fc: Not really.  Too cpu intensive, plus they do generate hashes where the tracks I mentioned above have identical hashes.
17.59.10 #        okey dokey - just a thought
17.59.13 #        HCl: Me neither.  It's annoying to have to FF through the silence.
17.59.51 #        fc: Although it's not clear with the latter is a desirable property or not.
18.00.07 #        maybe i should just add an disable runtime database option to the wps context menu so people can disable it for those specific albums, and just hash the middle?
18.00.19 #        I'm in favour of having a CPU intensive method and reading in old data first so you only generate a hash once.
18.00.25 #        like, the current design has no problem with disabling specific files
18.00.52 #        HCl: I dislike that idea.  You want those tracks in the db if possible.
18.00.53 #        what do you mean old data?
18.00.55 #        Cassandra: as I understood it their aim was to hash based on how it sounds??? so guess they would want them to hash to the same value
18.01.11 #        Songs you've already hashed once.
18.01.40 #        hrm..
18.01.47 #        that would require the old tagdatabase though
18.01.51 #        Yes.
18.01.54 #        and i know some people who were against that
18.01.59 #        and
18.02.05 #        it would make hashing on target practically impossible
18.02.25 #        which isn't really something i want since at some point its nice to have it add new files to the runtime database on its own
18.02.26 #        Could you grab 3 chunks from the; beginning, middle and end and hash those?
18.02.42 #        no, but i could grab a chunk of the middle and the end
18.02.54 #        but we'd still get problems with hidden tracks with a silence at the end
18.03.05 #        It wouldn't require the tagdb.  It'd just take a long time to generate a tagdb without the previous one.
18.03.06 #        the beginning has tags and isn't really suitable cause of that..
18.03.16 #        (Or for the first time.)
18.03.20 #        yea, i guess..
18.03.21 #        The end may also have a tag
18.03.25 #        (ID3V1)
18.03.27 #        erf.
18.03.38 #        but then you could get hash collisions anyway
18.04.37 #        There is no good solution to this problem.
18.04.47 #        ...and formats like ogg are even more complex, allowing multiple streams, which might be cut in another file etc...
18.04.51 #        I personally would favour accuracy over speed always.
18.05.11 #       * fogcat shuts up cos he knows he doesn't know anything about the structure of music files
18.05.20 #       * fogcat listens and learns
18.06.00 #        i'm fairly tempted to just take the middle of a file for now :/
18.06.39 #        as long as editing header/editing tags won't change the hash......
18.06.57 #        It would
18.07.07 #        There is no simple solution to this problem
18.07.14 #        even editing tags?
18.07.21 #        what tags happen in the middle of a file?
18.07.33 #        middle sounds fine
18.07.37 #        it doesn't have to be perfect, as long as it gets it right 99% of the time
18.07.43 #        would avoid header and tags I guess?
18.07.43 #        Yes. The tags might change in length, so the old middle is different from the new middle
18.07.51 #        hmm
18.07.52 #        gah!
18.07.52 #        ah
18.07.53 #        yes
18.07.54 #        ah.
18.07.54 DBUG    Enqueued KICK thegeek_
18.07.54 #        indeed
18.07.58 #        okay, that sucks.
18.08.00 #        how about a fixed offset into the file?
18.08.05 #        Same
18.08.15 #        the header would change in size?
18.08.20 #        fixed offset from the end of the file?
18.08.28 #        tags are stored at the end of the file are they not?
18.08.34 #        I don't know the ape format
18.08.36 #        but mp3 does?
18.08.47 #        Fixed offset from the end of file _might_ work, with at least 2 exceptions though
18.09.03 #        thegeek_: Tags are usually stored in the beginning, except id3v1
18.09.07 #        ah
18.09.08 #        yes;)
18.09.16 #        I remember I did some id3 stuff a long time ago
18.09.18 #        was prob v1;)
18.09.27 #        (1) If someone adds or removes an id3v1 tag
18.09.48 #        (2) If someone cuts away garbage from the end of the file
18.09.56 #        this is really an annoying problem... how about different hashes based on the filetype?
18.10.08 #        like we'd parse the mp3 slightly to find the first frame and hash from there
18.10.11 #        and i dunno about ogg
18.10.24 #        i guess ogg doesn't have id3v1? or does it?
18.10.29 #        no it doesn't
18.10.35 #        so it wouldn't have the fixed offset from the end problem
18.10.36 #        ?
18.10.37 #        No, ogg uses vorbiscomments
18.10.58 #        mp3 can have id3v1, id3v2 and/or apev2
18.11.09 #        (The latter we don't support yet)
18.11.17 #        i think the best for mp3 is to just read the offset of the first mp3 frame
18.11.19 #        and hash from there
18.11.27 #        and we could use the other method for ogg..
18.11.50 #        dinner
18.11.51 #        bbl
18.12.28 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
18.12.28 #       * t0mas wonders why we don't just use the middle + end... 
18.12.35 #        and give warnings on collisions
18.12.39 #        (on pc, not on target)
18.12.56 #        for most files... I can see if they really are the same with just the filename
18.13.02 Nick    Lynx_ is now known as Lynx_awy (~lynx@tina-10-4.genetik.uni-koeln.de)
18.16.33 #        HCl: Hmm, I just wondered what the hash is for after all....
18.19.02 Join    hardeep [0] (hardeeps@norge.freeshell.org)
18.24.58 Quit    Febs ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050511]")
18.27.53 Quit    fogcat ("CGI:IRC 0.5.4 (2004/01/29)")
18.29.11 Join    Maxime`Mrn [0] (~flemmard@fbx.flemmard.net)
18.29.31 Quit    Maxime (Read error: 131 (Connection reset by peer))
18.32.51 #        amiconn: its the link between the tagdatabase and the runtime database
18.33.33 #        t0mas: there's already an option to show duplicates, maybe i should enable it by default..
18.35.23 Join    TCK- [0] (TCK@81-86-208-155.dsl.pipex.com)
18.41.47 #        t0mas: end will give trouble with id3v1.. i'll just do middle for now..
18.46.03 #        k
18.48.41 #        hm wait.. :/
18.48.54 #        ah well >.<;
18.49.03 #        i can't keep account of everything, someday we'll have to find out a better way
18.49.19 Join    yyz [0] (~yyz@modem-2059.snake.dialup.pol.co.uk)
18.49.52 Join    Febs [0] (~chatzilla@64-190-36-240.client.cypresscom.net)
18.51.48 #        bah
18.51.56 #        we need to think of a good way :/
18.52.03 Quit    TCK (Read error: 110 (Connection timed out))
18.53.18 #        i don't feel comfortable with introducing a hashing algorhythm thats barely any better than the old one
18.53.56 #        *nods*
18.54.08 #        I wonder if you should introduce a seperate unique key.
18.54.31 #        There's something in the back of my mind about non-unique keying in databases being a bad bad thing.
18.54.50 #        nope, not in this case
18.55.08 #        the whole idea behind using a hash is having the same entry for the same songs
18.55.15 #        even when they're in different files
18.55.38 Join    fogcat [0] (~c2489e63@labb.contactor.se)
18.55.44 #        I don't think you're going to find a better solution than the one MusicBrainz have already come up with for that one.
18.55.46 #        and
18.55.49 #        i guess i'll go look into the mp3 frame thing
18.56.00 #        And I bet that involves parsing raw audio data.
18.56.24 #        forgive the stupid question but what is the hash to be used for? Identifying duplicate songs?
18.56.33 #        yes
18.56.43 #        You might want to look at the source for the MusicBrainz tagger and see if it gives you any ideas.
18.57.35 #        if people have tagged their files with the Music Brainz tagger (mp3s anyway) the hash is kept in the ID3v2 tags
18.57.51 #        Are they?  Now that *is* interesting.
18.57.57 #        iirc someone said music brains didn't hash any better than we did
18.58.10 #        In which case, all my MP3 files already have a unique hash sitting in their tags.
18.58.20 #        Sure they are... I use it on mine and I'm sure I've seen the data in there - not at home so can't check
18.58.54 #        I'd certainly welcome an option to use MB tags as keys.
18.59.40 #        Stupid Windows ID3 browser doesn't seem to show anything.
18.59.56 #        fc: What do you use to examine ID3 tags.
19.00.16 #        I've got the editor that you get with DBpowerAmp at home 
19.00.21 #        i need to talk to preglow, mabe
19.00.36 #        Hmmm?
19.00.56 #        he probably knows how i should read the mp3 header to get the offset of the first audio frame
19.01.01 #        I'll check when I get home anyway .. about time to go get the bus now
19.01.05 Quit    fogcat ("CGI:IRC 0.5.4 (2004/01/29)")
19.01.27 #        As to MB hashing better than us, I'm certain they would claim that their hashing is better.  (Although they do get dupes.)
19.03.46 #        *sighs* Winamp's tag editor is no better.
19.07.04 Join    bagawk [0] (1000@bagawk.user)
19.09.17 #        i wonder if i found something..
19.11.02 #        hah!
19.11.03 #        i love java
19.11.27 #        HCl: I trust you've read my comments
19.11.36 #        where?
19.11.47 #        earlier today
19.11.59 #        about your songdb
19.12.01 #       * HCl searches
19.12.03 #        java version
19.12.19 #        I lack code, docs and info on how/scripts to build it
19.12.27 #        there's also no license info
19.12.43 #        k
19.12.50 #        the code is inside the .jar at the moment..
19.12.54 #        if this is to be the recommended tool, I think those things should be added
19.12.58 #        yea
19.13.07 #        is that really all code?
19.13.14 #        yes
19.13.20 #        ok, goodie
19.13.48 #        I'm just lost in java so I didn't realize that
19.13.59 #        i'll search for the licenses soon, i dunno about putting it in cvs like that
19.14.08 #        i'll clean it up a bit too
19.14.16 #        but first i want to see if this hashing thing works..
19.16.14 #        hah.
19.16.15 #        sweet.
19.16.17 #        i love java
19.16.22 #        it just hashed based on audio data
19.16.25 #        rather than file data
19.16.31 #        with barely any code changes
19.16.48 #        and it falls back on file data if it fails to hash on audio data
19.18.25 Join    Chamois [0] (~Chamois@champigny-5-82-226-182-23.fbx.proxad.net)
19.18.54 #        HCl: http://wiki.musicbrainz.org/wiki.pl?MetadataTags
19.20.18 #        it doesn't say anything about the hash itself though? how unique is it? do files with the same audiodata get the same hash?
19.21.33 #        HCl:  That's the intention, yes.
19.22.21 #        HCl: How are the hashes in the runtimedb created?
19.22.24 #        well, i'd have to write support for reading them, but once thats in it shouldn't be too hard to make musicbrainz the priority
19.22.30 #        amiconn: copied from the tagdatabase
19.23.02 #        If they're just copied from the tagdb after looking up the path, and we don't verify the hash on target, why not just take the path for linking both databases?
19.23.36 #        because that would eliminate having the same runtime db entry for the same songs though they are at different locations
19.24.45 #        Ah right.
19.25.12 #        However, doing this properly would require hasing the pure audio data, without tags
19.25.18 #        yup
19.25.19 #        *hashing
19.25.28 #        and thats what i just implemented in the java version of songdb :)
19.25.34 #        with extreme ease too :)
19.25.41 #        just a matter of changing datainputstream to audioinputstream
19.25.54 #        Uh?
19.26.05 #        it hashes on audio data now, if everythings correct
19.26.14 #        and only falls back on file data when it fails to hash on audio data
19.26.20 #        You could verify that...
19.26.30 #        yea, it'd be nice if i could have a setup to test
19.26.38 #        Just copy a file you have, tag the copy different and then hash
19.26.38 #        its all theory so far, but it seems to work
19.26.45 #        yea
19.26.48 #        i'll do that in a sec
19.26.56 #        They should give the same hash regardless how you change the tags
19.27.04 #        yup
19.27.06 #        let me try that now
19.27.24 #        I would try 2 different cases
19.27.32 #        *5 cases
19.27.34 #        for mp3
19.27.37 #        only a problem if the audio-decoder changes...
19.27.51 #        _if_ (i don't know if it ever will *g*)
19.28.33 #        okay, didn't work :/
19.28.35 #        i think
19.28.37 #        HCl: Here's an explanation of TRMs (MusicBrainz tags): http://www.relatable.com/tech/trm.html
19.28.37 #        (1) File with both id3v1 and id3v2 (2) id3v2 only (3) id3v1 only (4) no tags (5) like 1, but with changed content in the tag(s)
19.29.03 Join    webguest09 [0] (~1804161f@labb.contactor.se)
19.30.16 Quit    webguest09 (Client Quit)
19.32.01 Join    Stryke` [0] (~Chairman8@cpe-24-168-110-99.si.res.rr.com)
19.32.28 #        i wonder whether this is a bug in my backend or just because the java webpage isn't entirely clear on what you get when you call read() on an audioinputstream..
19.33.39 #        well, at least i can tell you that the tritonus backend that i use is gpl
19.35.51 #       * Cassandra offers to have HCl's babies if he implements using MusicBrainz TRMs from the tags as a way of generating a hash.
19.36.21 #        eh..
19.36.33 #        you're scaring me o.o;
19.37.21 #        OK.  How about if I offer *not* to have your babies if you do it?
19.37.46 #        Cassandra: If there is no specific tool to examine file content like id3v2 tags, there's always the good old trusty hex editor...
19.38.31 #        ami: It's OK, I found where the tag info the MB client creates is documented.
19.41.24 Join    Coldtoast [0] (edan@ppp110-133.lns1.hba1.internode.on.net)
19.41.42 #       * HCl has to upgrade to a full-fledged tritonus backend..
19.42.15 #        Erm, you what?
19.42.39 #        java sound api implementation
19.43.03 #        Ah.  Reads mp3s, oggs etc. I take it.
19.43.27 #        yup..
19.47.30 Quit    hardeep ("[BX] Reserve your copy of BitchX-1.0c19 for Windows CE today!")
19.49.21 ***     Saving seen data "./dancer.seen"
19.52.27 #        I can't believe people still use bitchx
19.53.18 #        I remember helping panasync test it in his first few builds of it, when it was private to our IRC channel. And there were much better clients available
19.54.48 #        trm seems to require internet
19.55.19 #        To hash, yes.  To read from music that's already been hashed, no.
19.58.57 #        Summary Java MusicBrainz TRM Generator 
19.58.57 #        Categories  None  
19.58.57 #        License GNU General Public License (GPL 
19.58.59 #        there we go
19.59.09 #        *grins*
19.59.22 #        unfortunately, they don't seem to have any files submitted
19.59.23 #        x.x
19.59.32 #        Bugger.
20.00.20 #        Can I suggest making the first byte of your hash an indicator of the algorithm used to hash.
20.00.30 #        Then you can support multiple hashing methods.
20.00.42 #        oh wait
20.00.43 #        they do..
20.01.03 #       * Cassandra ponders dinner.
20.01.06 #        its just cvs only
20.01.25 #       * Cassandra bounces.
20.02.04 #        they only have the initial commit though
20.02.05 #        odd
20.03.45 #        ah.
20.04.03 #        got it :)
20.04.20 #        this should work fine
20.04.23 #        and its gpl
20.04.30 #        Bwahahaha!
20.04.56 #        I assume it still requires net access.
20.05.23 #        most probably, yes
20.05.49 #        http://www.inzyme.com/jtrim/index.html
20.05.53 #        for future reference
20.06.05 #        in case i forget the url or so
20.08.04 Join    XandriX [0] (~slack@xandrix.user)
20.08.11 #        seems easy enough, only problem is that the trm is a string, not an int
20.08.14 #        rockbox wth ?
20.08.17 Quit    bagawk ("Leaving")
20.09.44 #        erm...why does rockbox think Ogg is FLAC and MP3 is WAV?
20.10.01 #        Satan hates you.
20.10.10 #        Or it might be a bug.
20.10.16 #        it was working a few builds back :)
20.10.34 #        Sometimes fixing things breaks something else.
20.10.39 #        heh
20.10.55 #        I don't think the TRM generation itself requires internet. It's the TRM lookup in the musicbrainz database that does, but we don't need that
20.11.16 #        i dunno
20.11.19 Part    XandriX ("Leaving")
20.11.19 #        anywho
20.11.33 #        this is going to require a total rewrite of the filehash field in the database
20.11.39 #        since the trmid is a pretty long strin
20.11.40 #        g
20.11.49 #        ooer
20.11.58 Join    Lear [0] (~chatzilla@h177n6c1o285.bredband.skanova.com)
20.12.24 #        can someone put that in the buglist (Incorrect filetype displayed)? Ta.
20.12.47 #        HCl: We don't need to use that string as-is
20.13.01 #        mk.
20.13.12 #        whats an 406 response?
20.13.33 #        Is there an example how such a TRM id looks like?
20.14.03 #        Next track works much much better now
20.14.12 #        HCl: HTTP 406: http://www.checkupdown.com/status/E406.html
20.14.15 #        I can even scroll it no problemo
20.14.18 Join    webguest40 [0] (~d4406110@labb.contactor.se)
20.15.28 #        hrm.
20.15.34 #        jtrim gives me that response
20.15.44 #        		String trmId = "69ecc0fa-ef63-46ea-b6b7-531e44d8934c";
20.15.45 #        although it sometimes bugs out on Ogg when playing the first track some some Ogg's. Not a big deal though.
20.15.57 #        on some Ogg's rather
20.16.02 #        anywho, java can hash a string no problem so thats not really an issue..
20.16.19 #        jtrim is failing at the moment though
20.16.29 #        playback gets very confused if I skip two tracks and then FF the third, it zooms throught the third and then stops
20.16.36 #        C:\PROGRA~2\SONGDB~1\classes>java -cp . com.inzyme.jtrm.Main "C:\WINDOWS\Profile
20.16.39 #        s\HCl\Desktop\music\01 - Children.mp3"
20.16.41 #        java.io.IOException: Server returned HTTP response code: 406 for URL: http://trm
20.16.44 #        .musicbrainz.org/cgi-bin/gateway/gateway?4447
20.17.08 #        HCl: So the TRM is a just a hex string showing 16 bytes (4 longs)
20.18.28 #        Looks that way, unless the position of the -'s is significant.
20.18.44 #        My guess is that the musicbrainz server changed the request requirements somehow. -> Try to extract the hashing code and go without the lookup
20.20.26 #        amicon: http://musicbrainz.org/docs/20031108-2.html
20.20.32 #        amiconn: then i wouldn't be able to use tagged mp3s..
20.20.36 #        i'm looking at this log..
20.20.42 #        http://chatlogs.musicbrainz.org/2004/2004-10/2004-10-13.html
20.20.42 #        The TRM is generated by the server from internal hash data.
20.20.59 #        that guy had the same problem
20.21.04 #        he quickly said nevermind
20.21.08 #        but never said how he fixed it
20.21.38 #        Cassandra: Hmm, that's bad
20.21.53 #        This would be reason enough for me to drop TRM
20.22.28 #        We could use the audio signature part thouh
20.24.04 Join    MisticJeff [0] (~41ad57d4@labb.contactor.se)
20.24.10 #        Hi Gang..
20.24.19 #        no...
20.24.25 #        we can't drop trm cause its WAY too expensive
20.24.40 #        ?
20.24.43 #        It is rather sucky, isn't it?
20.24.43 #        it took 15+ seconds on my single test file
20.24.50 #        HC1:  please walk this noob through getting the database setup...  place SongDB.jar into root then what??
20.25.01 #        not root, .rockbox
20.25.10 #        java -jar SongDB.jar \
20.25.38 #        do i need to identify the location such as, D:\??
20.25.56 #        hey MisticJeff 
20.26.06 #        hey MisticJeff. heh
20.26.16 #        sigh, shouldnt rely on nick-tabbing and being in the right channel
20.26.48 #        hi guys
20.27.08 Join    webguest31 [0] (~c8378bfc@labb.contactor.se)
20.28.35 #        got it
20.28.41 Quit    webguest31 (Client Quit)
20.29.01 #        I've got unicode working again. The only problem is the fontsize: the one I'm using right now is 180kB.
20.29.06 #        C:\PROGRA~2\SONGDB~1\classes>java -cp . com.inzyme.jtrm.Main "C:\WINDOWS\Profile
20.29.10 #        s\HCl\Desktop\music\01 - Children.mp3"
20.29.13 #        178ad0e4-8c11-4ee3-b2d3-74b3469fe929
20.29.15 #         :)
20.29.48 #        Huh? Where's the function set_rating?
20.29.52 #        the only problem is that this heavily relies on an external internet server
20.29.57 #        screens.c
20.30.21 #        hcl: to which the source is proprietory/unavailable.
20.30.28 #        Cassandra: yea, heh.
20.30.32 #        This kind of sucks, like ami says.
20.30.46 #        i know
20.30.51 #        but i got it working anywho
20.30.58 #        markun: Font caching (!!!!!!!)
20.31.02 #        guess i'll wait a bit... if anyone can walk me through that tag db thing step by step please email me jeff at misticriver.net
20.31.12 #        amiconn: I know, but it's not so easy.
20.31.13 Part    MisticJeff
20.31.26 #        why didn't the \ work for him?
20.31.59 #        markun: There's a patch for supporting chinese, on archos. Maybe you can take some ideas from that
20.32.02 #        Odd... Wonder why I didn't get that through cvs update (or how I managed to get rid of it while hacking in screens.) :)
20.32.12 Join    hardeep [0] (hardeeps@norge.freeshell.org)
20.32.37 #        amiconn: right now every glyph that is not in the font is replaced by the default glyph. Would be useless to load a range of glyphs in the cashe if the are all just copies of the default glyph.
20.32.59 #        Yes of course
20.33.58 #        The caching would be necessary for fonts with more glyphs than which fit into the font memory space. We would only load the glyphs which are used
20.34.30 #        Gah, not even cvs diff picks up that set_rating is missing...
20.34.36 #        Slasheri; the FF is buggy right after skipping a track
20.34.38 #        ...possibly even swapping out some glyphs loaded earlier if we need new, unloaded ones and there is no more free memory
20.34.55 #        webguest40: hmm, what do you mean with that?
20.35.12 #        amiconn: Yes, I've thought about all that.
20.35.20 #        skip two track in a row, then FF as the track starts to play
20.35.31 #        ok, i will try
20.35.46 #        And I also have to keep an eye on the speed because looking up a glyph is something that is done a lot.
20.35.56 #        Yes
20.36.17 #        webguest40: if you mean the problem that elapsed counter goes to negative, that has been fixed in the latest bleeding edge
20.36.24 #        When a line is scrolling it could become a problem with the current implementation
20.36.30 #        no that that problem new one
20.36.35 #        oh
20.36.38 #        Still, caching is simply necessary if we want true unicode support, that works for chinese/japanese/korean etc
20.37.15 #        webguest40: are you using crossfade? and the latest bleeding edge build?
20.37.22 #        markun: Not necessarily. We'd need to preload the glyphs for all characters in the scrolling line
20.37.26 #        yes latest, no crossfade
20.37.34 #        ok, i will turn crossfade off
20.38.29 #        webguest40: and you are using mp3 files?
20.38.36 #        yes mp3
20.38.40 #        Some educated guessing on what glyphs might be needed might be needed as well. E.g. the ascii glyphs should always be available etc
20.38.44 #        LAME-aps
20.38.49 #        i tried start playing, then skipped few tracks and did FF.. no problems so far
20.38.56 #        amiconn: For single quotes I use u 0x2019 in my ogg tags. Right now you cannot have it in a font without having the other 0x2018 as well (most of them copies of the default glyph)
20.39.18 #        you need to start FF as soon as the next track starts playing
20.39.46 #        webguest40: ah, thanks i found it :)
20.39.50 #        Slasheri: You got around to looking at why the resume code doesn't clear itself properly at the end of a playlist yet?
20.39.53 #        markun: The default glyph should only ever get cached once
20.39.53 #        :)
20.40.02 #        amiconn: yes, it should
20.40.02 Quit    TCK- (Read error: 104 (Connection reset by peer))
20.40.03 #        Cassandra: no, haven't looked that yet
20.40.10 #        Cassandra: are you seeing that in the latest build?
20.40.17 #        Cassandra: it was working fine for me
20.40.19 #        ...regardless how many code positions use it
20.41.01 Join    TCK [0] (TCK@81-86-99-239.dsl.pipex.com)
20.41.11 #        amiconn: I had some ideas but they involve a lot of pointers and with 4 bytes each it got very big.
20.41.14 #        Slasheri: but there is a problem with resume -- offset is being updated too early (not taking latency into affect?) so we're resuming a few seconds later then where we stopped
20.41.36 #        Hrm.. I'm getting all sorts of odd problems now.
20.41.37 #        markun: Yes, pointers for every glyph might not be the right solution
20.41.41 #        s/affect/account
20.41.47 #        when I change songs its back to about 4 seconds when I skip forward one song...
20.42.01 #        and it plays part of the next song and "slips" back into the last song for half a second then plays the rest of the new song...
20.42.02 #        Again, I recommend looking at the chinese rockbox patch, perhaps there are some good ideas...
20.42.36 #        I have the patch here, I'll take another look later.
20.42.51 #        there
20.42.55 #        and then we should have a hash based on trm
20.43.05 #        if --usetrm is used
20.43.05 #        that is
20.43.12 #        hardeep: Hmm, that's true..
20.43.44 Join    thegeek [0] (na@ti521110a080-7313.bb.online.no)
20.45.28 #        godzirra: that problems seems to appear with crossfade disabled.. will be fixed :)
20.46.28 Quit    yyz (Connection timed out)
20.47.39 #        igh.
20.47.48 #        trm is slowwwwwwwwwwwwwwww
20.48.29 #       * HCl stares at his +- 140 songs testcase..
20.48.37 #        HCl: But if you write it to the ID3 structure, you only ever need to calc it once.
20.48.41 #        HCl: It uses the decoded audio to make the trm tag, so it's not strange that it's slow.
20.48.52 #        how would it take to do 37gigs
20.48.55 #        Cassandra: yea, i know... i don't have the infrastructure to write to the id3 tag at the moment though..
20.49.25 #        i'll go see if my backend supports it and if not find a backend that does
20.49.35 #        wg:  Quite a while.  (Hours, I imagine.)
20.50.04 #        I reran it on my entire music database a while back and it took a good 30 mins or so.
20.50.11 #        For about 4000 tracks.
20.50.20 #        p4
20.50.34 #        doesn't trm calculation also require a network roundtrip
20.50.39 #        Yes.
20.50.49 #        But that isn't the bottleneck.
20.51.11 #        oh, I always thought it was
20.52.51 #        the entire tcp session took 0.7 seconds here for a single file - 200ms for the actual POST to get a reply
20.53.25 #        Well, you can calculate the next one in the background while the lookup is going on.
20.53.56 #        well yeah, the entire procedure spends close to 4 seconds real time, so it clearly is not the bottleneck
20.54.39 Join    ghode|afk [0] (~dude@host-212-158-195-60.bulldogdsl.com)
20.54.46 #        30 minutes for 4000 tracks? seems fast to me
20.55.00 #        its doing 7 minutes for just 170 tracks here
20.55.04 #        and thats on my local harddisk
20.55.08 Join    CheeseBurgerMan [0] (~Dan@63.150.80.229)
20.55.14 #        on top of that.
20.55.21 #        its even being a worse hash!
20.55.37 #        but that might be due to me hashing the hash
20.55.54 #        worse hash?
20.55.55 #        it found two duplicates that are not duplicates
20.56.03 #        but
20.56.13 #        it did properly find duplicates of two files with different id3v2 tags
20.56.24 #        trm collisions are rather common in my experience
20.56.27 Part    webguest40
20.56.33 #        ......
20.56.41 #        then whats the point of trm >.<
20.56.52 #        HCl: to detect what *song* it is, not what *mp3* it is
20.57.02 #        yes thats what we're trying to do
20.57.08 #        and different encodings vary so much that it is bound to be difficult
20.57.24 #        i will check the trm hashes..
20.57.34 #        you don't want to detect different encodings of the same song?
20.58.32 #        ah...
20.58.35 #        i know why it failed
20.58.38 #        Hadaka: If network roundtrip is a problem, parallelize the requests
20.58.43 #        jtrm only works for mp3s so far
20.58.45 #        (makes for a nice DoS)
20.58.46 #        the duplicates it got were oggs
20.58.52 #        okay..
20.59.15 #        sorry, I entered the conversation midway, so I don't know what people are trying to accomplish
21.00.00 Quit    thegeek_ (Read error: 110 (Connection timed out))
21.00.01 #        ARgh, archos fm/v2 rockbox isn't far away from the final size barrier :(
21.00.34 Quit    ghode|afk ()
21.00.43 #        *nods to amicon*  We might start having to make Rockbox light for the Archos.
21.01.07 #        Slasheri: another playback bug (in build from yesterday at least): at the end of a playlist, playback stops when the codec buffer is empty; it doesn't keep playing until the end of the PCM buffer...
21.02.56 #        anyway, like I said, I have gotten numerous TRM collisions from my mp3 collection - and also different encodings generate different TRM ids so I end up with multiple TRMs for the same song
21.03.13 #       * HCl kicks trm and song hashes :/
21.03.27 #        TRM is just a heuristic
21.03.38 #        Like we already said.  There are no good solutions to this problem.
21.03.41 #        heh. for a heuristic its pretty darn slow
21.03.53 #        Cassandra: There is quite a number of spots where we can decrease code size. Spots where we use duplicated (or nearly duplicated) code now, that can be converted into one function...
21.04.13 #        I personally detect my mp3's (as I want to differentiate by different encodings) by taking an md5 sum of the first 30 seconds of the decoded PCM audio data
21.04.27 #        yea, thats what i'm wanting to do
21.04.34 #        but i'm getting really tired of this
21.04.41 #        I could take the MD5 sum from the mpeg frames themselves, but this way it works for every audio format that is deterministic in decoding
21.04.42 #        i'm spending way too much time on it..
21.05.06 #        and my point is just to detect mp3's that have had garbage prepended or suffixed or which have been truncated
21.05.33 #        i think i'll just throw the musicbrainz approach away
21.05.43 #        mainly because it depends on an external internet server
21.05.46 #        Hadaka: Doing that won't allow to hash on the target later.
21.05.48 #        *nods*
21.06.21 #        Decoded PCM will differ a little depending on the decoder used for lossy formats
21.06.57 #        the musicbrainz thing is nice to interactively detect which song a certain mp3 is - I think it as a layer on top of the mp3 detection
21.07.06 #        I don't see why we can't rely on tag info and say mistagged files are the user's problem.  Garbage in, garbage out.
21.07.25 #        amiconn: really? I know that's true when the stream has errors since decoders handle errors differently - but do they handle valid data differently as well?
21.07.42 #        Yes, definitely.
21.08.40 #        amiconn: ah right, then I have to ditch this approach in the long term (and make sure I use the same decoder always in the short term)
21.08.40 #        The first thing are roundoff errors. They depend on the algorithm, the math precision, whether they used fixed or floating point...
21.09.06 #        The next thing is that decoders may sacrifice precision for speed
21.09.16 #        Slasheri: just making sure someone new about the probs :)
21.09.35 #        Slasheri: that mp3 metadata thing I mentioned yesterday (if you saw it...): I just uploaded a patch fixing that (#1232957). Feel free to apply it. :)
21.09.48 #        amiconn: right
21.10.33 Join    LinusN [0] (~linus@labb.contactor.se)
21.10.46 #        Hrm... Preparing multiple patches, with changes in the same file, is no fun... :)
21.10.59 #        Lear: quilt is your friend
21.11.16 #        Huh?  cvs diff -u does it all for you.
21.11.51 #        Hadaka: Huh? What has quilt got to do with it. Goggle didn't show anything else that seemed reasonable...
21.11.59 #        Cassandra: except if you want to have a new patch on top of your old patch?
21.12.06 #        Cassandra: But here I have two different patches, both meddling with the same file...
21.12.14 #        Ah.  Messy.
21.12.31 #        Lear: quilt makes handling a patch series easy, and makes it easy to rebase them and refresh them and such
21.13.09 #        bah
21.13.31 #        The Win32 simulator is messy (less messy than the x11 sim, but still...)
21.17.29 #        can anyone tell me what I am doing wrong for next track in wps? I want it to pull info from the ID3 tag but it's not working. I can only pull the filename or directory name
21.19.05 #        oh ignore that I think I know what I am doing wrong (Impatient)
21.19.09 #        Are you putting it on scrolling lines?
21.19.41 #        I keep forgetting the 2mb buffer up rule
21.19.55 #        it works on scrolling lines Cassandra
21.20.13 #        the new build has a quick fix to show filename and directory info...lets see if it changes after the 2mb buffer up
21.20.27 #        ct: If it does, that's pure luck.
21.20.30 #        bah.
21.20.39 #        Scrolling WPS lines don't support dynamic update.
21.20.51 #        just the first time you play a track and it has the info, it doesn't update the wps with the info til you seek or change tracks
21.20.57 #        Lear: thanks, i will apply it :)
21.21.18 #        just that firsttime. After that, when you just let a playlist play, it updates correcrly
21.21.25 #        i need to talk to preglow..
21.21.36 #        *nods*
21.21.41 #        or anyone else who knows how to get the offset of the first mp3 frame
21.22.11 #        dohhhh
21.22.14 #        hm.
21.22.17 #       * HCl stares.
21.22.23 #        %s%?Ia< %Ia| %Fn>
21.22.23 #        %s%?It< %It>
21.22.25 #        rockbox just has a field with the offset.
21.22.36 #       * HCl goes to figure out how this field is calculated
21.23.15 Join    TCK- [0] (TCK@81-86-100-202.dsl.pipex.com)
21.23.16 #        that's what I use. First track you play just displays the filename, which is instant. It works nicely for me
21.23.22 #        Lear: what is your realname?
21.23.29 #        HCl: you're not referring to the resume related offset are you?
21.23.34 #        that's something different
21.23.36 #        no
21.23.39 #        just the first track you play gets the filename instead. That's ok for me
21.23.45 #            entry->first_frame_offset = bytecount;
21.25.57 #        gotta go, cu l8r
21.26.00 Part    LinusN
21.27.49 #        aha.
21.27.51 #        okay
21.28.06 #        that was easy, says man, and he procedes to prove black is white and gets killed at the next zebra crossing
21.34.05 Quit    TCK (Read error: 104 (Connection reset by peer))
21.35.05 #        hm, well, not as easy as i originally though.
21.35.05 #        t
21.35.17 #        hrm.
21.40.03 #        okay
21.40.04 #        well
21.40.11 #        i don't know about ogg vorbis comments
21.40.22 #        what about them?
21.40.23 #        but it skips id3v2 now and hashes the first 32kb of the first frames
21.40.31 #        dunno how to skip them
21.41.32 #        not trivial, but if you read the vorbis spec, you will be enlightened. :) Short version: skip first two Ogg pages (or rather, first ogg page, and then first vorbis packet on the second page).
21.41.42 #        Though I doubt that made much sense to you. :)
21.43.42 #        mhm..
21.43.47 #        i hate song hashing.. 
21.44.02 #        i added the beeping skipping of id3v2, why doesn't it work..
21.45.35 #        it doesn't seem like tritonus is very reliable
21.45.38 #        but i knew that already..
21.48.02 #        why can't all song tags be at the end?
21.48.38 #        because if you're streaming it then you dunno wtf it is till its over
21.48.39 #        heh
21.49.15 #        aha..
21.49.23 ***     Saving seen data "./dancer.seen"
21.49.31 #        ...and if your file's truncated
21.49.39 #        then you never know wtf it is
21.49.40 #        hehe
21.49.40 #        well i'll just put this on the wiki anyways
21.49.49 #        its *slightly* better
21.57.27 #        :) :) :) 4-level greyscale in the win32 simulator :) :) :)
22.00.29 #        wee
22.00.57 #        nice
22.02.26 #       * HCl scribbles some documentation on how to use the java tool onto the wiki
22.02.38 #       * HCl is still annoyed over song hashing..
22.02.51 #        tritonus is a really bad backend..
22.03.04 #        i should replace it :/
22.04.32 #        t0mas: any chance that you might be able to implement a line drawing tag to the wps?
22.06.07 #        amiconn: does rockboy utilize the 2bit grayscale yet?
22.06.17 #        Yes it does
22.06.23 #        (In fact it has to
22.06.24 #        k good :) enabled the define then?
22.06.24 #        )
22.06.27 #         :p k
22.06.34 #        No, changed the define
22.06.42 #        well, that works too
22.06.49 #        #if LCD_DEPTH == 2
22.06.54 #        *nods*
22.07.17 #       * HCl ended up all unmotivated after messing with hashing for 4 hours without much result, goes to wander around :/
22.07.26 #        The only thing missing is a nice 4-grey ROCKbox logo
22.07.37 #        mmm, why?
22.07.54 #        I could commit without, but I don't want to
22.07.58 #         :p
22.08.02 #        *nods*
22.08.08 #        what about wps images?
22.08.35 #        The current b&w logo works with 4-grey as well, but obviously in b&w only. Dull.
22.08.41 #        mhm
22.09.15 #        wps images should work the same as now, in b&w
22.09.32 #        There won't be much visible difference at the start
22.10.06 #        Only (1) rockboy uses 4-grey (2) The splash() boxes will have a light grey background (3) The logo, if I manage to do that
22.11.11 Quit    RotAtoR ()
22.13.22 Join    PaulJ [0] (~PaulJ@vpn-3040.gwdg.de)
22.15.17 #        does anybody know what the english expression for ehm... "school french" or something like it is?
22.15.22 #        so really bad french?
22.15.38 #        in dutch: Huis tuin en keuken frans -> house garden and kitchen french
22.16.28 #        school is ecole in french iirc
22.16.43 #        I can't seem to find the perfect wps yet. Sigh...
22.17.14 #        anychance of that allignment patch for wps being committed?
22.18.00 #        t0mas: there isn't one, afaik
22.18.06 #        Stryke`: someone was looking at it (Cassandra?)
22.18.43 #        Stryke`: Cassandra is looking at ti
22.18.44 #        *it
22.18.47 #        ok, sounds good
22.18.51 #       * HCl goes to look at the submitted patches
22.18.52 #        and it will be committed tonight, or tomorrow
22.19.01 #        great news, thanks
22.19.39 #        http://amiconn.dyndns.org/WinSim-grey.png
22.20.14 #        nice :)
22.20.22 #        first time i see rockboy run in a sim
22.23.31 #        In fact it should be more playable in the sim than on target
22.23.45 #        (1) No speed problem (2) No button constraints
22.24.16 #        yup
22.24.52 Quit    PaulJ (Read error: 145 (Connection timed out))
22.26.23 #       * HCl looks at the patch for the chip emulator
22.29.11 #        Hmm... Does anyone else get the wrong codec name in the WPS?
22.32.09 #        too bad, missing file from the chip8 patch..
22.32.13 #       * HCl registers for an sf account..
22.32.24 #        Yep, id3.c and id3.h aren't in synch...
22.32.39 #        hm?
22.41.50 Join    tvelocity [0] (~tony@chan530-a065.otenet.gr)
22.44.30 #        Lear: you want your cvs access fixed/restored?
22.45.14 #        oh
22.45.17 #        Bagder: Linus fixed that about an hour ago. I've even started comitting... :)
22.45.25 #        Ah, you noticed...
22.45.26 #        I _just_ noticed that
22.45.38 #        when reading mails waiting for your reply ;-)
22.46.01 #        back to lurk-mode
22.46.11 #        Bagder: Btw, you've seen my oggvorbis patch? Needs updates, but is it still of interest?
22.46.32 Quit    Febs ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050511]")
22.46.37 #        I haven't checked it out, I trust your judgement
22.50.23 #        Bagder: added playcount and rating to wps.. if you're interested..
22.50.42 #        I noticed and I am interested, I'll upgrade and try it out soon
22.50.49 #        you're gonna have to regenerate your database though, there was a critical bug in the binary search..
22.51.44 #        I made mine with the perl script
22.52.29 #        I didn't see any updates to that, was it?
22.53.00 #        eh
22.53.02 #        nope
22.53.16 #        the perl script isn't gonna be capable of runtime database till it gets a hashing function
22.53.39 #        and that is not gonna happen until you describe what it is and how it works
22.53.58 #        very simple, just a crc32 of the first 32kb of the files
22.54.34 #        can you from now on please clearly describe all file format changes
22.54.48 #        i haven't made any file format changes..
22.54.49 #        we have two tools now, soon to be three
22.55.14 #        well, you made up the format and it isn't easy to track devel nor format
22.55.20 #        sorry
22.55.28 #        *checks the wiki*
22.55.38 #        i'll add a comment about the hash field
22.56.06 #        Stryke`: Alignment patch is in my local source tree.  I'm fixing formatting issues at the moment.
22.56.49 #        does it allow for partial formatting? alligning left some text and right others on the same line or not yet or not feasible
22.57.09 #        That's actually something I'm working on fixing too.
22.57.23 #        sounds great
23.00.06 Part    Lear
23.01.14 #        maybe someone will eventually make an app for designing wps in...maybe :)
23.01.23 Quit    tvelocity ("Leaving")
23.01.28 #        hehe.
23.02.02 #        Just been playing with trying to get bmp's to sit right with the text
23.02.12 #        font sizes mess with that something awful
23.02.37 #        Bagder: pretty much, the perl tool has to implement http://rasher.dyndns.org/~rasher/hash.c, and use CalcCRC32 on the first 32768 bytes of each file
23.03.24 #        "and" ?
23.03.30 #        isn't that code crc32?
23.03.51 #        ah
23.03.52 #        now I see
23.03.57 #        CalcCRC32 is the name of it
23.05.53 #        yea
23.06.15 #        i marked the spot in the perl tool where the hash should go
23.08.30 #        and the runtimedb uses that to figure out what song it plays?
23.10.06 #        it uses that to link a song to a runtime database entry
23.10.32 #        so if two files have the same hash they will also have the same (shared) runtime info
23.10.53 #        so if you move files you won't lose your runtime info, among other things
23.13.41 #        i'd better go sleep
23.14.44 #        Bagder: Where can I find that super-hires rockbox logo bitmap?
23.15.11 #        tomorrow i'll rewrite the databasev2 wiki a bit to reflect the way things are now
23.15.35 #        amiconn: http://www.rockbox.org/viewcvs.cgi/*checkout*/www/tshirt-contest/Attic/rockbox3540.jpg
23.16.14 #        Thanks... so it was in cvs once...
23.16.49 #        gnight
23.17.00 #        HCl: and things no longer correct should be removed from the TagDatabase I think
23.17.08 #        (the wiki page I mean)
23.17.14 #        okay
23.17.15 #        good night
23.17.16 #        i'll do that too
23.23.55 #        HCl: I guess it is up to 32K and less if the song is shorter?
23.31.38 #       * Cassandra swears at the WPS display code.
23.34.27 #       * Rori swears with you
23.34.30 Join    einhirn [0] (Miranda@carlsberg.heim2.tu-clausthal.de)
23.39.07 #       * t0mas swears with you both
23.39.21 #        Cassandra: maybe we can try to move some things arount
23.39.24 #        *around
23.40.33 Join    stripwax_ [0] (~stripwax_@213-228-241-36.dsl.prodigynet.co.uk)
23.40.48 #        ello
23.45.15 Part    CheeseBurgerMan
23.46.18 Quit    einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
23.47.04 #        hey. there's a problem wit my WPS. it used to work, and now. the retreiving next song data doesn't disappear when the data is received. its the GeorgeCollins on the wps gallery :S
23.47.11 #        t0mas: It's OK.  It's just very difficult to do multiple aligned strings on a single line with the current structure.  I'm trying to think of a good way to solve this and failing.
23.49.27 ***     Saving seen data "./dancer.seen"
23.50.12 #        anyone?
23.52.04 #        No idea, sorry.
23.53.54 #        Hmm.. does the CF5249 have a branch predictor?
23.54.13 #        No idea
23.55.02 #        west-acre  - between which versions of rockbox did it work and not work?  ;-)
23.56.18 #        stripwax_: A very simple one
23.56.50 #        It assumes backward branches are most likely taken, and forward branches most likely not