--- Log for 23.12.105 Server: brown.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 16 hours and 46 minutes ago 00.01.02 # <_FireFly_> ok now they are in the wiki 00.01.09 # is there an assembly optimised ifft for coldfire ? 00.01.17 # <_FireFly_> lets the discussen begins about it ;) 00.01.51 # <_FireFly_> now it is really time for bed for me good night everybody 00.01.59 # nite _FireFly_ 00.02.33 Quit _FireFly_ ("Leaving") 00.02.39 Join Lear [0] (n=chatzill@h184n5c1o285.bredband.skanova.com) 00.02.53 # maybe I can reuse one from a codec 00.04.43 Join edx [0] (i=edx@p54A86637.dip.t-dialin.net) 00.08.58 # amiconn: there? 00.09.03 Quit |u|smooth (Read error: 104 (Connection reset by peer)) 00.09.09 # LinusN: yes 00.09.47 # * amiconn just noticed the issue date of the HD66789R datasheet 00.09.52 # amiconn: i was about to ask about the time display on the ondio 00.09.59 # but i realized it has no rtc 00.10.37 # yaay 00.10.46 # Yes, that's why we were able to reuse the clock area for the MMC icon 00.10.48 # * warewolf asked earlier about h300 rtc 00.13.13 # Too bad we can't use high speed data write for the H300 lcd 00.13.19 Quit DiveineIn (Read error: 104 (Connection reset by peer)) 00.14.28 Quit Lear ("Chatzilla 0.9.69 [Firefox 1.5/0000000000]") 00.14.42 # How does the current lcd_write_data() ensure correct timing at 124 MHz (namely the minimum inactive period for /WR) ? 00.15.49 # firefly- nice...i see your wiki pages 00.15.52 # thanks for sharing 00.16.13 # so you are gonna try to implement that work? 00.18.57 # I can't build the current cvs 00.19.11 # settings_menu.c: In function `brightness': 00.19.11 # settings_menu.c:220: error: `LANG_BRIGHTNESS' undeclared (first use in this function) 00.19.42 # You're building non-english? 00.20.23 # yes french 00.21.31 # hmmm do you need to add a new setting to all LANG files or does it fall back to english? 00.21.33 # Then you need to update french.lang with the new string firast 00.22.02 # petur: Rockbox falls back to the built-in language for strings not present in the loaded .lng file 00.22.11 # amiconn: don't know wha it is 00.22.24 # The standard is to build english, then builtin is english and english is the master 00.23.25 # * amiconn always chooses english as built-in language 00.23.30 # ah, so if you're *building* with another language, that file should be up-to-date... 00.23.35 # yup 00.23.54 # who's responsible for updating the LANG files? 00.24.22 # .lang files aren't assigned to specific maintainers 00.24.47 # Should I have added them to my patch? 00.24.50 # Everyone who feels like it can file a patch, or change himself when he has commit access 00.25.32 # amiconn: why not defaulting to english parameter ? 00.25.48 # time to get some sleep. goodnight 00.25.53 Quit petur ("here today, gone tomorrow") 00.25.57 # you load the english file, then after that the other language file 00.26.11 # and #defines are redefined 00.26.15 # can it work ? 00.26.24 # The standard way for a new string is to add it to english.lang, and optionally to your own language. I'm sure there is *no* contributor who knows all supported languages 00.26.43 Nick Lost-ash is now known as ashridah (n=ashridah@67.106.77.212.ptr.us.xo.net) 00.27.30 # what I said could work or it's not feasible ? 00.28.14 # ?? 00.28.30 # ? 00.28.53 # #defines are evaluated at build time, they can't be changed at runtime 00.30.54 # I know 00.31.34 # but the configure could include the english file first, then include the target language after that 00.31.46 # the defines would be overridden 00.31.54 # can it work ? 00.32.13 # :) 00.33.43 # Well, perhaps, but why? Imho the build language selection causes more confusion and problems that it's worth. Just choose english as builtin language. You can always choose another .lng file in the settings 00.33.55 # I agree 00.34.04 # we should probably remove that ability 00.34.13 # I always needed to change it anyway 00.34.41 # remove it yes 00.34.55 # gets my vote too 00.34.58 # * bagawk is in agreement 00.35.36 # One could argue that the builtin language saves a tiny bit of battery power by not having to load a .lng file, but imho this is neglectible 00.35.49 # The RAM is set aside anyway 00.36.08 # ...and many other things are loaded from disk, like fonts,... 00.36.24 # rockbox 00.36.26 # ... 00.36.50 # ok, let's rip it out 00.36.57 # mirak: Not necessarily 00.37.09 # ? 00.37.14 # On archos it's possible to load/run rockbox from flash 00.37.58 # One day this will also be possible on iriver. 00.38.03 # is it normal that the battery never reach full charge ? 00.39.02 # mirak: how do you know that it isn't fully charged? 00.39.22 # because the UI doesn't say it ... 00.39.30 # :) 00.39.37 # the most annoying part with skipping the language selection is updating a billion automated builds! ;-) 00.39.39 # why does it look like it never reach full charge ? 00.39.44 # mirak: so your question is: "is it normal that rockbox never displays full charge?" 00.39.46 # mirak: that's a detection issue, not a charge issue 00.40.00 # (last i checked anyway) 00.40.16 # did the iRiver firmware turn off the charging circuitry when it showed that fully charged icon, or is stopping charging handled entirely in hardware and it stops charging by hardware? 00.40.35 # @ 00.40.39 # the charging is handled by the pcf50606 chip 00.41.17 # LinusN: you said somewhere the H300 can't work without using the battery 00.41.21 # is it right ? 00.41.23 # mirak: the answer is: the battery level hasn't been calibrated on the iriver players 00.41.33 # LinusN: Did you get my last question? 00.42.13 # amiconn: the h300 lcd transfer loop is so slow that it didn't need any timing adjustments 00.42.23 # because of the slow dram access 00.42.35 # Hmm. That was the same with DMA? 00.42.39 # yes 00.42.56 # since it interleaved dram and lcd accesses 00.43.00 # With burst-read that will no longer be the case 00.43.11 # perhaps not 00.43.38 # Well, the waitstates only stretch the /WR active time, correct? 00.43.44 # correct 00.43.54 Quit gromit` (Read error: 104 (Connection reset by peer)) 00.44.06 Join Membrillo [0] (n=sam_kill@CPE-144-131-86-7.nsw.bigpond.net.au) 00.44.29 # We need at least 70 ns /WR inactive time which equals 9 CPU cycles at 124 MHz 00.44.38 # :-( 00.44.58 # how long is a swap in iram? 00.45.16 # word swap is a register operation, 1 cpu cycle 00.45.27 # so 2 for the fetch and 1 for the execution 00.45.32 # right? 00.45.34 # Uh, following the trend on the language page of labelling each file how the language is said in that language, Japanese should be labelled Nihongo 00.45.51 # No, just one cycle once the code is cached 00.46.00 # no cache in iram 00.46.01 # (japanese language in japanese) 00.46.24 # but iram access is 1 cycle anyway, roght? 00.46.31 # yes 00.46.47 # so 2 cycles for a swap 00.46.52 # No, 1 cycle 00.47.16 # ok, the fetch is piped 00.47.27 # yes 00.47.43 # IRAM is 1 bus cycle, code cache is 1 CPU cycle? 00.48.03 # and the move.w -(ax) is how many? 00.49.32 # We don't need the decrement, but that doesn't matter anyway. move.w Dn,(Ax) is also just 1 cycle 00.49.48 Nick ashridah is now known as Lost-ash (n=ashridah@67.106.77.212.ptr.us.xo.net) 00.50.07 # ...with one write access, which will of course be 1 bus cycle == 2 cpu cycles (16 ns) 00.51.21 # 1 bus cycle is 3 cpu cycles iirc 00.51.46 # plus wait states 00.51.57 # busclk == cpuclk/2 00.52.11 # so it is 6 then 00.52.23 # ? 00.52.35 # You mean the 2 waits? 00.53.03 # no, i mean that an access is 3 bus cycles == 6 cpu cycles 00.53.39 # ??? 00.53.53 # and each wait state is 1 bus cycle == 2 cpu cycles 00.54.23 # Why should one access take 3 bus cycles (w/o wait states)? 00.55.11 # cycle 1: drive address 00.55.31 # cycle 2 + waitstates: perform the read 00.55.46 # cycle 3 + waitstates: release the address 00.55.59 # all in all 3+ws bus cycles 00.56.26 # write cycles are the same 00.56.55 # this is of course regular static ram accesses, sdram is of course different 00.57.17 # Hmm, it seems I overlooked somehing in the datasheet 00.57.20 # and iram is also different 00.57.30 # Isn't the write buffered? 00.57.37 # not that i know of 00.57.55 # (and i hate that) 00.58.05 Quit Membrillo () 00.59.00 # the 5249 can burst sram accesses, 3-2-2-2 00.59.46 # If the write needs 3 bus cycles anyway, we might need less wait states in a number of places 00.59.58 # write and read of course 01.00.10 Quit akaidiot ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 01.00.30 # amiconn: where? 01.01.09 # afaik, we have 0 waitstates everywhere 01.01.13 # E.g. flash rom, but that needs testing 01.01.19 # We don't 01.02.48 # which one is not 0 waitstates? 01.03.19 # We use 2 waitstates for LCD at 124 MHz, 4 waitstates for flash ROM at 124 MHz, and 1 waitstate for flash ROM at 45 MHz 01.03.51 # ah, silly me 01.03.57 # Back when I added flash ID reading for h1x0, there were only 2 waitstates for flash at 124 MHz 01.04.16 # That was definitely not enough, as I got only garbage 01.05.14 Quit webguest95 ("CGI:IRC (EOF)") 01.05.55 Part Sando 01.07.25 # I'm a bit confused. Is this a 70ns or a 90ns ROM? 01.07.33 # 70 01.08.01 # Hmm. Then I wonder why 2 waitstates at 124 MHz weren't enough 01.08.39 # A bus cycle is ~16ns at 124 MHz (busclk == 62 MHz) 01.09.00 # That means, 3+2(wait) * 16 ns == 80 ns 01.09.22 Quit ender` (" "Religion is the opiate of the masses." -- Karl Marx "Winners don't do drugs." -- The FBI") 01.13.36 # weird 01.13.55 # it's LA time... 01.14.15 # unfortunately, i'm 500 kilometers from my la 01.14.37 *** Saving seen data "./dancer.seen" 01.15.01 # Well, taking into consideration that /CS active time is only 2 bus cycles, 3 waitstates should be enough at 124 MHz 01.15.32 # ...but the one waitstate at 45 MHz shouldn't be necessary at all. However, it is necessary... 01.15.50 # badness 01.16.30 Join San [0] (n=test@A-57-80.cust.iol.ie) 01.17.18 Join akaidiot [0] (n=nope@c-5846e255.363-1-64736c11.cust.bredbandsbolaget.se) 01.18.17 Join mymomthelush [0] (n=lush@69-172-214-124.ontrca.adelphia.net) 01.18.39 Part mymomthelush 01.22.06 Quit tvelocity ("Leaving") 01.24.40 # LinusN: Perhaps it's my fault after all. There's an additional setup time when reading the flash ID. 01.24.50 # aha... 01.25.00 # Nevertheless a LA measurement should help to make things clear 01.25.05 # absolutely 01.26.49 Quit t0mas (Read error: 104 (Connection reset by peer)) 01.28.22 # Software ID Access and Exit Time: 150 ns 01.30.10 # there you go 01.31.25 # Otoh, I vaguely remember that just reading the ROM with 2 waitstates delivered garbage. Seems some experimentation is due 01.31.56 Quit linuxstb (Read error: 110 (Connection timed out)) 01.32.32 # (Dump ROM contents) 01.32.38 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 01.36.04 Quit bazz ("Leaving") 01.38.59 Quit Moos ("Happy birthday Rockbox") 01.39.46 # ok 01.40.33 # otoh, i don't care that much about flash access time right now 01.40.46 # lcd is more important 01.47.53 Quit dpassen1 (Read error: 110 (Connection timed out)) 02.00.15 Join ryan_ [0] (n=chatzill@adsl-69-231-39-78.dsl.irvnca.pacbell.net) 02.01.43 # time to sleep, nite alll 02.01.56 Part LinusN 02.02.54 Quit ryan_ (Client Quit) 02.11.57 Join DiveineIn [0] (n=eran_yar@87.69.22.69.cable.012.net.il) 02.25.26 Join Sando [0] (n=lolsteam@techgaming.net) 02.28.21 Quit mirak ("Ex-Chat") 02.59.58 Quit dropandho () 03.05.00 Quit miner49er ("using sirc version 2.211+KSIRC/1.3.11") 03.06.31 Join Jungti1234 [0] (n=jungti12@58.77.81.144) 03.14.41 *** Saving seen data "./dancer.seen" 03.20.22 Join ghode [0] (n=garudin@host-84-9-105-221.bulldogdsl.com) 03.20.36 # RTC support!! 03.21.50 Quit ghode|afk (Read error: 110 (Connection timed out)) 03.22.53 # anyone? 03.24.26 # Bger!! 03.51.27 Join nathanh [0] (n=wosjowj@220-245-216-23-act-pppoe.tpgi.com.au) 03.52.38 # woot, rockbox rocks boxes 03.57.34 # RTC display in WPS needed now. 04.12.58 # is the rtc code written for every platform? adding the tag to wps is easy 04.22.26 Quit San (Read error: 104 (Connection reset by peer)) 04.43.52 Quit akaidiot (Connection timed out) 04.52.30 Quit actionshrimp ("a bird in the bush is worth two in your house") 05.00.28 Join DivineInt [0] (n=eran_yar@87.69.22.69.cable.012.net.il) 05.13.42 # nathanh: lots of code, unless I missed something -- I'm about done with it 05.14.11 # lets the user display time using basically 'date' syntax (w/o the %s, and only supporting a limited number of format options) 05.14.44 *** Saving seen data "./dancer.seen" 05.15.26 # tops stuff, lots of people have been asking for rtc 05.17.14 Quit DiveineIn (Read error: 110 (Connection timed out)) 05.18.08 # I hope it doesn't impatct WPS performance, because it's about the most complex tag. 05.27.15 # well, i got some thoughts about that 05.27.35 # i implemented a display lists patch - basically lets you have any order of images and tags - but its sloooow 05.27.50 # i cant play an ogg at the same time as the display list on my h300 (mp3 works ok though) 05.28.01 # i profiled it and the majority of time is spent in format_display 05.28.10 # that parsing code parses the wps file - tags and all - every single frame 05.28.16 # grossly inefficient 05.28.26 # so before i push a display lists code im working on a tokenizer 05.28.43 # the parser will take the wps and generate a list of tokens - bytecode if you will - and that will be what format_display runs through 05.28.51 # i expect to drop the cost of wps displaying down to nothing 05.29.05 # that's basically what I suggested on patch tracker, isn't it? 05.29.08 # ? 05.29.13 # dunno, maybe 05.29.25 # i dont recall what you said :-) 05.29.35 # my latest comment on one of your patches, basically said preparse the WPS as much as possible 05.29.47 # ok, so we're on the same frequency :-) 05.29.50 # because yes, tokenizing it every effing time through was teh bad 05.29.52 # totally. 05.30.13 # so now that sdl is out of the way ive got 3 patches i want to write - color bmp loads (working, needs tweaking) 05.30.18 # then tokenized wps 05.30.23 # then i'll redo the display lists code 05.30.29 # you must have time on your hands. 05.30.30 # :) 05.30.34 # im on holiday! 05.30.45 # starting as of 2 hours ago 05.31.14 # I'm on a four day weekend, but I'll be out of town w/o internet access for it starting at 6am :( 05.32.06 # anyway, the tokenizer should be fairly simple 05.32.12 # ive already got a doodle on a bit of paper about how to do it 05.32.46 # yeah, I had some theories on it, kinda a pain to move much of the existing WPS code into it, but nothing inherently _hard_ 05.33.31 # the best bit about this project is the lead devs are all keen on doing the hardware 05.33.39 # which is great, because i despise working with hardware 05.33.53 # so i get to muck about with all the cool stuff that they're not interested in :-) 05.34.22 # lol, I like anything that's down in the works C... because I work all day in high level Java and I need a change of pace 05.37.55 Quit DreamTactix291 () 06.18.24 # hmph, the value of get_time() is only updating every 5-7 seconds 06.18.32 # otherwise time formatted display works. 06.19.46 Join San [0] (n=test@213-202-165-82.bas503.dsl.esat.net) 06.30.21 # http://sourceforge.net/tracker/index.php?func=detail&aid=1388592&group_id=44306&atid=439120 <-- RTC in WPS first whack. 06.31.13 Join DreamTactix291 [0] (n=DreamTac@adsl-156-26-186.bna.bellsouth.net) 06.34.00 Join akaidiot [0] (n=nope@c-4346e255.363-1-64736c11.cust.bredbandsbolaget.se) 06.36.02 Nick Lost-ash is now known as ashridah (n=ashridah@67.106.77.212.ptr.us.xo.net) 06.54.30 Quit akaidiot (Read error: 110 (Connection timed out)) 07.03.20 Quit nathanh (Read error: 110 (Connection timed out)) 07.05.46 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 07.14.47 *** Saving seen data "./dancer.seen" 07.18.12 Join nathanh [0] (n=wosjowj@220-245-216-23-act-pppoe.tpgi.com.au) 07.19.45 Quit paugh ("Leaving") 07.36.55 Quit nathanh ("Quit") 07.39.34 # http://mfiles.naver.net/9647a07c6d335be8c19d/data15/2005/12/23/42/rockbox_rtcwps.zip : 12-23 build + RTC in WPS patch 07.40.00 # is yours better than mine? 07.41.30 # no 07.41.41 # what's the difference? 07.41.42 # same. 07.42.47 # oooh that's just a _build_ of rockbox with it patched? 07.43.24 Quit RotAtoR ("zzzzzzz") 07.43.37 # yes 07.47.38 # I'm working on adding day and month names ;) 07.47.40 # should be sleeping. 07.48.01 # hehe 07.50.40 # patch file updated with (hopefully) localized day and month name support (date format tags a and b) 07.54.35 # oh.. 07.56.15 # just tryin' to torture you with new versions ;) 07.56.59 # :) yes. 07.57.11 # torture -_-; 08.06.47 Quit Bger ("bbl") 08.09.31 # oh no Bger.. 08.14.57 # hey lostlogicx 08.23.50 # lostlogicx, Are you there? 08.23.55 # yes 08.35.42 Join ender` [0] (i=ychat@84.52.165.220) 08.39.17 Join Membrillo [0] (n=sam_kill@CPE-144-131-86-7.nsw.bigpond.net.au) 08.40.09 # Does anyone know the reason behind the overscroll in dir view and when scanning around songs? 08.40.28 # slow LCD updates. 08.40.36 # according to LinusN 08.41.17 # ah ok 08.42.48 # lostlogicx: Success! 08.43.21 # party on, hopefully it's merge worthy :) 08.43.33 # hahaha 08.44.10 # I want to mark date by Oriental style. 08.44.33 # What is oriental style? 08.44.35 # yyyy-mm-dd, am(pm) hh:mm 08.44.55 # that should be supported by my patch 08.45.52 # but 08.46.17 # I want 'yyyy-mm-dd (day of the week)' 08.46.45 # numeric day of the week? ahh... I missed that didn't I. 08.46.48 # 2005-12-23 Fri 08.47.23 # %cY-m-d ac 08.48.09 # mark order date 08.48.15 # ok 08.48.20 # :) thanks 08.49.10 # Do you think it is worth adding numeric day-of-week? 08.49.22 # yes 08.49.28 Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) 08.49.43 # Convenient. 08.49.49 # for what? 08.50.04 # what day number is monday to you anyway? 08.50.30 # I don't understand. 08.50.45 # Bagder: for date in WPS formatting -- the unix date command standards is what I've been using, and they say monday is 1, and Sunday is either 7 or 0 08.51.00 # sure 08.51.00 Quit edx (Read error: 104 (Connection reset by peer)) 08.51.09 # but that doesn't mean it makes sense to many people to use it 08.51.16 # I mean displayed 08.51.19 # yeah, I guess no harm in supporting it. 08.51.25 # lostlogicx: Imho it would be sufficient to make weekday and month a combined numeric/multiple alternative conditional, like volume and battery level 08.52.07 # that might be nicer, as it will then be easier for multiple languages or using bmps 08.53.16 # hmmmmm... I could switch from using a single date string to format dates to using multiple separate date tags, but then I'd want to cache the rtc tm value somewhere rather than reading it from get_time for each separate date related tag. 09.01.11 Join georgeblunt [0] (n=georgebl@82.149.71.170) 09.09.50 Join miner49er [0] (n=miner49e@82-32-84-226.cable.ubr01.chap.blueyonder.co.uk) 09.10.33 Quit Membrillo () 09.11.10 Join _FireFly_ [0] (n=icechat5@pd95b7c08.dip0.t-ipconnect.de) 09.14.23 # nice 09.14.51 *** Saving seen data "./dancer.seen" 09.15.07 Join DJDD_ [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) 09.19.56 # added 'u' and 'w' for numeric DOWs. I leave it up to someone else to split it into subtags and not over-call get_time if that would be preferred / needed to get it merged. 09.25.17 # -_-; 09.25.49 # Again update? 09.30.14 # only if you want the w and u tags... 09.30.45 # what is w and u? 09.31.22 # 1 is start monday? 09.31.31 # 1 = u 09.39.31 Join muesli- [0] (n=muesli_t@141.71.4.222) 09.40.04 Join Bger [0] (n=Bager@83.222.160.88) 09.43.05 # hey Bger 09.43.32 # hey, Jungti1234 :) 09.43.36 # I waited you. 09.44.12 # the korean patch ? 09.44.44 # New Korean translation wasn't included to build today. 09.45.39 # I have other new Korean translation. 09.45.46 # Send it to you. 09.47.47 # How do I send it to you? 09.48.18 # Thinking about the rtc-wps patch, I think it could be useful to add a strftime function to rockbox, and use that. 09.48.32 # i.e. size_t strftime(char *s, size_t max, const char *format, const struct tm *tm); 09.48.56 # I would quite like the option to display the date in the status bar - there is more than enough room on the larger LCDs. 09.49.21 # amiconn: It seems we need to do a little compromise with the tag cache on archos players. When user wants to update the cache (for example add new files), it's faster to completely rescan the disk than add only changed files. That also means that the db should be build at once while the player is running. Iriver is more flexible when using dircache, as there is no need to rebuild the cache when adding files and player can be rebooted any time 09.49.36 # Long.... 09.50.38 # Jungti1234 the same place 09.50.48 # I don't know. 09.52.59 # ...But thinking about strftime, that will need to go into apps/ if it is to use localisation. 09.57.51 Quit muesli- (Read error: 104 (Connection reset by peer)) 10.01.19 Quit Vlad0man (Read error: 110 (Connection timed out)) 10.01.44 Join Vlad0man [0] (n=Vladoman@p54A7D768.dip.t-dialin.net) 10.08.11 Quit San (Read error: 110 (Connection timed out)) 10.13.29 # Slasheri: I wonder why a complete rescan is faster than an incremental update on archos, when it's the other way round for iriver. Is there a reason for this? 10.15.35 # amiconn: yes. When doing incremental scan on archos, we need to check from the disk if the file already exists in the db. And that checking takes some time 10.15.47 # on iriver, we can do the same check from ram and it's fast 10.16.12 # <_FireFly_> due the dircache :) 10.16.17 # yep :) 10.16.42 # <_FireFly_> but when someone disable dircache then it is also slow in iriver 10.16.49 # <_FireFly_> s/in/on 10.16.58 # _FireFly_: yes, but then the db cannot be loaded into ram at all 10.17.28 # Slasheri: So... that doesn't mean it depends on the target, but rather on dircache being enabled or not 10.17.42 # I have dircache disabled on iriver 10.17.47 # in fact, speeding up that disk based incremental checking would be possible by creating other index file.. 10.18.13 # amiconn: yep, that's true. But for ram loading, it also needs some additional space to load the tag indexes 10.19.08 # amiconn: hmm. When using readdir, should it return files always in same order? 10.19.08 # Would it be possible to speed up scanning by using additional ram? If so, tagcache build could be faster when playback is stopped, using the audio buffer 10.19.23 # if that is the case, then we could just continue the search from the previous place in the file 10.19.37 # amiconn: yes, that could be possible 10.19.58 # Slasheri: Yes, as long as the dir isn't changed. readdir() returns the entries in 'natural' order 10.20.17 # ah, that sounds good. In fact, it might solve the issue :) 10.20.26 # i will try that 10.20.29 # It might happen that a new entry ends up in between the list of old entries 10.21.03 # yep, but that shouldn't be a problem as long as the order is not entirely much changed 10.21.06 # -much 10.21.15 # That'll happen if there are some deleted entries. They'll get reused if a new entry is created 10.25.27 # Do you already have ideas how to browse this? I imagine a number of virtual directories, and perhaps a search function? 10.25.55 # At the moment, i have ported the dbtree browser to it (so browsing and searching works) 10.26.28 # Sounds like a working solution. Perhaps some more virtual directories could be added later 10.26.40 # yes, should be possible 10.26.44 # The old db code should be removed imho 10.26.47 # i already added the genre browsing too 10.27.54 # Another change which I would like to see is the separate browsing mode removed, and the tag browser added as a virtual sub-dir of the root, similar to the multivolume support on Ondio 10.28.08 # amiconn: in fact, it would be great if you could test the code on real archos later 10.28.24 # This virtual sub-dir would only be shown if the tagcache is present (built) 10.28.52 # ah, that sounds like a great idea 10.28.54 # ...and enabled. Is there an option to enable/disable the tag cache? 10.29.19 # lostlogicx 10.29.59 # no, there is not an option for that (only on iriver, user can select whether to load the cache to ram or not). But user has to request the cache to be built if it's not present 10.31.59 Part miner49er 10.33.05 # Ah, but once it is built, it wil be kept up-o-date all the time? What if a user just wants to test the tag cache, and then decides he doesn't want it? 10.33.47 Join miner49er [0] (n=miner49e@82-32-84-226.cable.ubr01.chap.blueyonder.co.uk) 10.33.58 # amiconn: it will kept automatically up-to-date only if it's loaded into ram. At all other cases, user needs to request for a cache update/rebuilding 10.34.15 Part miner49er 10.34.29 # ok 10.35.22 # lostlogicx: Are you there? 10.39.19 Join miner49er [0] (n=miner49e@82-32-84-226.cable.ubr01.chap.blueyonder.co.uk) 10.44.27 Quit Jungti1234 ("bye") 10.49.02 Join DiveineIn [0] (n=eran_yar@87.69.22.69.cable.012.net.il) 10.50.57 Join edx [0] (i=edx@p54A86637.dip.t-dialin.net) 10.52.48 # Slasheri: Does anything happen if a user deletes a file on their player (via Rockbox) ? 10.53.25 # linuxstb: yep, then tagcache just stops working and needs to be rebuild 10.53.44 # oh, you mean a song file 10.53.48 # Yes. 10.54.04 # currently that is not detected.. so the file will still show in the cache 10.58.25 # Slasheri: Your tagcache will solve the itunesdb problem in the ipod port. Currently, Rockbox isn't able to browse files that have been copied to the ipod via iTunes (they are stored with obfuscated filenames). But tagcache will find them and add them to a unified database with the rest of the music on the device. 10.59.32 # ah, interesting 10.59.41 # iTunes stores the tags both in the files themselves and the ipod's itunesdb database. 11.00.15 # Hmm, then it could be possible to convert that itunesdb into other format 11.00.33 # or just read the files.. 11.00.35 # Yes, that would be an optimisation. But even without that, it would still work. 11.00.43 # yep 11.01.03 # itunesdb is a constantly moving target - it would be better IMO to just leave it alone. 11.01.36 # in fact, we could even build in future the itunesdb from tagcache to allow runtimedb info synchronization with other programs 11.03.34 # I'm not that interested in itunesdb - I don't use iTunes and I can't see myself ever using the Apple firmware. I guess we'll find out if there is a demand from ipod users when they start using Rockbox. 11.05.09 Quit DivineInt (Read error: 110 (Connection timed out)) 11.05.16 # hmm, true 11.05.50 Join eli_sherer [0] (n=eli@IGLD-83-130-178-5.inter.net.il) 11.08.50 # hello everybody with an H300 please read: http://www.misticriver.net/showthread.php?t=33960 11.10.08 # that's insane, a whole screenful of colourful, ugly stuff before the article text appears :o 11.10.15 # now someone code a new tetris for H100 :) 11.10.37 # eli_sherer: You say you use the original graphics from Tetris. Are we legally able to use those in Rockbox? 11.10.38 # i can make it grayscale for the H100 it'll be just as nice... 11.11.01 # yup the patent on the graphics are way overdue... 11.11.05 # ? 11.11.12 # Graphics aren't patented - they are copyrighted. 11.11.18 # copyright lives 70 years after the creator's death 11.11.25 # lol 11.11.25 Join Polo_o [0] (n=polo_o@82-69-160-166.dsl.in-addr.zen.co.uk) 11.12.13 # well i bet that russian dude that made tetris will like what i did... besides... i changed it a lot do it fits the h300 screen 11.12.21 # crwl: If you register and login at mistic river, you can change the "theme" to something more reasonable. 11.12.46 # that default theme is bound to scare lots of people away 11.13.01 # have you seen that Linus made RTC support for the H300???? (Linus your the greatest) 11.13.32 # linuxstb, mmhm... that's kind of cumbersome 11.13.40 # crwl: Don't blame me :) 11.13.45 # you know, i first thought that theme was an april fools joke or something :) 11.14.53 *** Saving seen data "./dancer.seen" 11.16.29 Join nathanh [0] (n=wosjowj@220-245-216-23-act-pppoe.tpgi.com.au) 11.17.44 # eli_sherer: Seriously, if you've copied the original tetris bitmaps without permission, I don't think your plugin will be accepted into Rockbox CVS. Which will be a shame, as it looks great. 11.17.55 # screenshot url? 11.18.13 # http://www.freewebs.com/eli_sherer/ 11.18.26 # (click on Tetrox) 11.18.41 # looks like the original :-) 11.19.16 Join Paul_The_Nerd [0] (n=Paul_The@cpe-66-68-93-2.austin.res.rr.com) 11.19.19 # linuxstb: i don't know how to upload my stuff to the rockbox CVS so... 11.20.17 # eli_sherer: you provide patches to the patch tracker and then someone with commit access add them to CVS 11.20.35 # i didn't really took the origianl stuff it's just a port guys... every port of tetris on the web has the same graphics and no one took premissions...just the splash screen i took from wikipedia and that's it the rest i cam up on my own... 11.21.06 # if you took the graphics, you don't have the right to it 11.21.08 # period 11.21.26 # unless the creator gives you the right 11.21.49 # we take these matters seriously in Rockbox 11.22.12 # let me clarify what are we talking about: the so called "graphics" is only the splash screen which i took from wikipedia and that's it 11.22.21 # ok 11.22.31 # and wikipedia gives the right to use the graphics 11.22.36 # so then you're clear 11.22.39 # i'll check it right now... 11.23.00 # Bah, the last korean.lang updates each time remind me that l10n v2 is overdue :( 11.23.42 # i checked and it is copyrighted but can be used for non profit organizations....is it good? 11.25.22 Quit dwihno (Remote closed the connection) 11.26.11 # good, but not good enough for inclusion in Rockbox 11.26.30 # it would violate the GPL 11.26.57 # no worry...i'lll think of another picture to put on the splash screen... 11.26.59 # but GPL's for code 11.27.15 # not exactly 11.27.18 # gpl is for anything, not just code 11.27.36 # ze: not really. it makes most sense for code, but it can apply to anything, really. 11.27.40 # since it would be part of the distribution, everything needs to be gpl "compatible" 11.27.56 # but yeah, it's the non-profit -only bit that's the issue 11.28.15 # yeah i suppose 11.28.33 # "imposes further restrictions" 11.28.38 # eli is doing lots of good stuff with colour plugins :-) 11.28.48 # indeed! 11.29.15 Part Sando 11.29.35 # now if only somebody with cvs commit access would commit that truly awesome colour starfield patch... 11.30.59 # <_FireFly_> nathanh on the wiki is my first attempt to design a token-based wps-handling if you want to look at 11.31.21 # ooo, neat, i was gonna look at that but im happy if somebody has already done it 11.31.35 # nathanh which patch ? 11.31.44 Quit Paul_The_Nerd ("Leaving.") 11.31.51 # <_FireFly_> nathanh not all aspects are completet 11.32.19 # <_FireFly_> nathanh: it is maybe an goo starting-point 11.32.32 # bger: https://sourceforge.net/tracker/index.php?func=detail&aid=1379549&group_id=44306&atid=439120 11.32.34 # <_FireFly_> s/goo/good 11.32.37 # firefly: thanks, i shall check it out 11.32.47 Join Paul_The_Nerd [0] (n=Paul_The@cpe-66-68-93-2.austin.res.rr.com) 11.33.18 # <_FireFly_> it is located under Specs and Papers 11.33.38 # firefly: yup, found it 11.34.44 # <_FireFly_> the biggest problem will be the token-generation on targets with low ram-space e.g. the archos recorder with 2MB ram 11.35.19 # can make it smaller by not sucking in the whole .wps file but reading it line by line 11.35.42 # <_FireFly_> that is currently already done 11.36.23 # im talking about format_lines in wps_data struct 11.36.25 Join dwihno [0] (n=dw@81.8.226.44) 11.36.40 # no need to have those lines at all 11.36.43 # i think the starfield looks great "as is" but you can add gray scale to emulate depth... 11.36.57 # far stars will be darker... 11.37.04 # eli: currently emulates depth by drawing more pixels 11.37.12 # eli: stuff far away = 1 pixel, closer = 4 pixels, so on 11.37.19 # <_FireFly_> nathanh currently the format_lines have only the needed lines from the wps no bitmap-loading lines 11.37.32 # firefly: i see 11.37.33 # yeah but brightness is another aspect of depth emulation... 11.37.52 # <_FireFly_> for the tokens you need enough tokens in ram for the wps because there is no real malloc to create new tokens dynamically 11.37.58 #