--- Log for 02.07.105 Server: brown.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 21 days and 22 hours ago 00.00.11 # I tried your line on it's own. no difference 00.00.19 # amiconn: it should probably be possible to uncomment part of the unused tagdatabase support functions 00.00.33 # Bagder: 3.3.1 -> 3.3.5 saves almost 1 KB ... 00.00.35 Join ze [0] (ze@ca-dstreet-cuda2-c9a-73.snbrca.adelphia.net) 00.00.39 # i'm planning to use them later in order to be able to add fileentries to the tagdatabase on the fly 00.00.43 Join p3druskus [0] (~petru@37.Red-80-37-10.pooles.rima-tde.net) 00.00.59 # HCl: That might be helpful 00.01.07 # does your next track scroll too with 'artist - title'? 00.01.10 # with my line, it displays "unknown artist -" on teh first track til it gets past the frst 2MB barrier. Then it loads the correct info and fills it in. When the track changes, it changes to the new info 00.01.13 # and all scrolls 00.01.47 # gah. too many interesting programs on discovery channel 00.01.50 # you know that lines like this: 00.01.53 # * HCl just turns it off before he starts to watch it 00.01.54 # I hope that [IDC]Dragon finishes bootbox testing some day. Then rombox shouldn't be a problem anymore on all archoses 00.01.56 # Artist. %s%?ia<%ia|%?d2<%d2|[\root]>> %?ig<(%ig)|%t0> 00.02.03 # scrolsl teh WHOLE line? 00.02.07 # whats bootbox? 00.02.18 # you don't get static "Artist" with scrolling artist name 00.02.30 # the whole line including "Arttist" scrolls 00.02.48 # On archos, we have a dual-boot bootloader also developed by [IDC]Dragon which allows to boot 2 different firmwares from flash 00.03.25 # Any of the 2 can be either compressed (then it needs to be uncompressed into ram before execution) or uncompressed and executed directly from rom 00.03.51 # btw MO-Pantsu 00.04.00 # The first image serves as a backup and is only started if you hold a button while booting 00.04.01 # you can actually alter a few of your conditionals 00.04.18 # In our current flash packages this first image is the archos firmware, compressed 00.04.26 # you don't need things like ?%Ia<%a|> 00.04.34 # I just need a line that works....sigh 00.04.38 # The second image, which is started normally, is usually rockbox 00.04.46 # oops 00.04.57 # I mean ?Ia<%Ia|> 00.05.11 # just use ?Ia<%Ia> 00.05.12 # 'rombox' means uncompressed rockbox, executed directly from rom and hence leaving some more free ram for buffering etc 00.05.33 # "The else part is optional, so the "|" does not have to be 00.05.33 # specified if no else part is desired. 00.05.36 # " 00.05.39 # that's from teh docs 00.05.40 # The problem is that this isn't possible on all units due to space constraints 00.05.44 # I have aq headache now 00.05.47 # (the rom is only 256KB) 00.05.59 # can't be bothered anymore 00.06.06 # if it's some weird bug it's evading me 00.06.37 # here 00.06.54 # accept the dcc 00.07.06 # it's not downloading for some reason hold on 00.07.08 # So [IDC]Dragon works on replacing the alternate firmware image (the archos one) with a stripped-down rockbox which is only able to charge (for archoses which have software controlled charging), allow USB access, and boot from HD 00.07.09 Quit MO-Pantsu () 00.07.11 # this works on mine 00.07.16 # *This* is bootbox 00.07.22 Join Rori [0] (MO-Pantsu@deadman3000.plus.com) 00.07.34 # try again 00.07.53 # nup 00.07.58 # ah just paste the damned thing 00.08.10 # heh 00.08.30 # there you go 00.10.46 # HCl: Could you please disable the unused parts for now? 00.11.15 # kay. 00.11.29 # Hmm. 00.11.37 Join Stryke` [0] (~Chairman8@cpe-24-168-110-99.si.res.rr.com) 00.12.57 # The unused functions are only for updating the tagdb on the target, or is there more? 00.13.22 # committed 00.13.27 # nope, thats it 00.13.36 # tnx :) 00.13.48 # Let's see if that brings back my rombox.... 00.13.57 # * HCl goes to shower 00.14.02 # ...at least temporrily 00.17.39 # can you add a parameter to .wps so you can display %ff in KHz as well? 00.18.24 # yes you can 00.18.59 # Rombox isn't back :( 00.19.11 # Output is 524 bytes larger than max (192496) 00.19.33 # then hardeep's next-dir thing is probably those ~500 bytes 00.19.57 # Must be more 00.20.37 # runtime database is still a fair amount of extra code.. 00.20.56 # I guess your gcc 3.3.1 will give ~1500 bytes too much, but rombox was possible before even with that gcc 00.21.20 # Output is 644 bytes larger than max (192496) 00.21.35 # Uh? Interesting... 00.21.41 # very! 00.21.46 # Why is that? 00.22.13 # I would expect a roughly proportional decrease 00.23.21 # I know that it would bring rombox back if I compile with -Os (and I know the fix to make it run with that -O option) 00.23.45 # ...but I don't think that we want -Os 00.24.15 # Bagder: did you say you CAN get %ff to display as KHz? 00.24.26 # sure, just write the code 00.24.50 # heh. if I were conversant in C, I'd love to 00.25.39 Quit Stryke` ("Friends don't let friends listen to Anti-Flag") 00.26.02 # gnight 00.27.06 # good idea 00.33.19 Quit spiralout (Read error: 131 (Connection reset by peer)) 00.43.52 Join TCK [0] (TCK@81-86-98-63.dsl.pipex.com) 00.45.45 Join bug_ol_paul32432 [0] (~d1ced0bc@labb.contactor.se) 00.46.48 # what is the easiest way to reset ur iriver?? 00.48.54 Quit bug_ol_paul32432 (Client Quit) 00.49.08 # OK guys. Me and Coldtoast have been testing the next track thing and I have a weird problem 00.51.11 # for some reason I can't get next track artist to display when playing the first track. Ever. Not even if I wait until the end of the track. Yes the condition is in there as advised by the wps docs 00.51.38 # yes there is an id3 tag and tried swapping id3v1 to v2 and back 00.52.06 # ONLY if I FF a little on the first track played does it then display the artist for the next track 00.52.33 # It always shows the title when it buffers part way through the first track but never the artist for the next track unless I FF 00.53.12 # yeah. on my player I get the info right near the end but when he does exactly the same thing I do, his doesn't do it 00.54.23 # using his wps btw 00.54.28 # just to make sure 00.54.33 # tried various tracks 00.54.59 # they have correct ID3 tag info. using clean latest build of rockbox. Odd eh? 00.55.30 # the fact it reads the tag for artist after I FF makes it even odder 00.55.53 # The tag is read always 00.56.06 # it's just not displaying if I let it play 00.56.17 # I think there is a bug in wps code that it doesn't detect the info changed and the display should be updated 00.56.18 # only when it gets to track 2 it then shows artist correctly for track 3 00.56.33 # yep methinks so too 00.56.51 # that bug has been driving me crazy for 2 days 00.57.13 # wondering why I could not get next track info to display correctly 00.57.29 # I better head to be. it's 9am 00.57.46 Quit Coldtoast ("Peace and Protection 4.22") 00.57.50 # thanks for the help 00.58.04 # at least I know it's not me being dumb 01.09.01 Join webguest72 [0] (~d49f4cf2@labb.contactor.se) 01.09.07 Join n0bby [0] (~fake@40-218.207-68.tampabay.res.rr.com) 01.17.15 Quit Rick (Read error: 104 (Connection reset by peer)) 01.17.29 Quit Ancelot () 01.18.11 Join Rick [0] (~rick@pool-71-108-23-179.lsanca.dsl-w.verizon.net) 01.18.49 Quit Harpy (Read error: 145 (Connection timed out)) 01.22.40 Quit webguest72 ("CGI:IRC") 01.25.24 Join wlad [0] (wlad@200.139.133.172) 01.30.22 # is the top line always off limits for wps? 01.46.55 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.46.56 Quit n0bby (Read error: 104 (Connection reset by peer)) 01.47.32 *** Saving seen data "./dancer.seen" 01.55.09 Quit p3druskus ("leaving") 01.55.46 Part Moos 01.58.19 Quit hicks (Remote closed the connection) 02.01.05 # Argh! The runtimedb handling is bad bad bad! :( 02.01.21 # It causes a spinup for *every* track change! 02.17.56 Join PaulJ_ [0] (~PaulJ@vpn-3005.gwdg.de) 02.19.03 Quit PaulJ_ (Remote closed the connection) 02.19.09 Join amiconn_ [0] (~jens@p54BD515E.dip.t-dialin.net) 02.22.01 # shame on you HCl 02.22.04 # ;p 02.23.15 Quit amiconn (Nick collision from services.) 02.23.15 Nick amiconn_ is now known as amiconn (~jens@p54BD515E.dip.t-dialin.net) 02.26.35 # * amiconn is severely annoyed by the runtimedb code 02.26.52 # * amiconn goes to sleep 02.29.21 Join n0bby [0] (~fake@36-219.207-68.tampabay.res.rr.com) 02.34.24 Quit courtc (Read error: 110 (Connection timed out)) 02.35.03 Quit PaulJ (Read error: 113 (No route to host)) 02.36.07 # anyone here know where does the damm ATJ2085 MCU boots on? (rom address) 02.48.26 # nope 02.48.28 # i wouldnt anywat 02.48.33 # -t +y 02.50.20 # =( 02.50.35 # there is absolutely no info on that chip ... 02.50.50 # just a very imcomplete datasheet ..... 02.52.58 Join kenshin_ [0] (~dave@c-24-17-8-193.hsd1.wa.comcast.net) 02.54.59 Nick wlad is now known as wladston (wlad@200.139.133.172) 02.57.28 Quit wladston () 03.04.24 Join wacky_ [0] (~wacky@modemcable011.4-37-24.mc.videotron.ca) 03.04.39 # hey guys, do you know a way to have warnings and errors highlighted in a bash shell, while running gcc ? 03.05.00 # nope. never seen a way to do that. 03.05.48 # but usually gcc just bombs on errors (making them obvious) and warnings are usually okay to skip 03.05.50 # I've seen that on a friend's computer, it was all highlighted.. and he didn't do anything really weird, it was by default on a Mandriva distro... 03.08.58 # there must be a package that tweaked /etc/profile.d in some way ?! 03.09.47 # i've only seen highlighting on the bash prompt and ls 03.12.18 # Mandriva may have customized bash to recognize gcc errors and warnings 03.13.10 Quit skel_ (Remote closed the connection) 03.13.34 # and i don't see any gcc options to do this 03.15.50 # oh :) just installed gcc-colorgcc :) 03.15.55 # it's a perl wrapper that colorizes the output :) 03.15.55 # nice 03.19.04 Quit n0bby (Read error: 110 (Connection timed out)) 03.24.30 Part wacky_ 03.37.49 Join tvelocity [0] (~tony@ipa201.6.tellas.gr) 03.47.34 *** Saving seen data "./dancer.seen" 04.00.18 Quit Rick ("I… don't need to be here.") 04.00.31 Join Rick [0] (rick@pool-71-108-23-179.lsanca.dsl-w.verizon.net) 04.01.11 Quit Rick (Client Quit) 04.01.22 Join Rick [0] (rick@pool-71-108-23-179.lsanca.dsl-w.verizon.net) 04.06.08 Join QT_ [0] (as@area51.users.madwifi) 04.09.01 Quit ShockerEngr (Read error: 145 (Connection timed out)) 04.17.34 Quit QT (Read error: 113 (No route to host)) 04.17.38 Quit kenshin_ (Read error: 110 (Connection timed out)) 04.17.43 Quit xen` (Read error: 110 (Connection timed out)) 04.20.10 # anyone fancy tackling that wps updating display bug? :) 04.59.07 Join Leperkawn [0] (~chatzilla@68-188-193-92.dhcp.mrqt.mi.charter.com) 05.02.42 Join n0bby [0] (~fake@40-218.207-68.tampabay.res.rr.com) 05.15.59 Join kenshin_ [0] (~dave@c-24-17-8-193.hsd1.wa.comcast.net) 05.17.08 # So, what are your opinions on me getting a h3x0 through those free dealies and sending it to the rockbox devs? 05.24.26 # the devs who need the 3x0 (for writing the bootloader) already have them 05.26.33 # Ah. 05.26.39 # Well, then. 05.26.45 # I will just have to sit by and wait. 05.32.00 # have no fear, development is in progress 05.34.29 Quit n0bby (Read error: 110 (Connection timed out)) 05.47.35 *** Saving seen data "./dancer.seen" 05.56.29 Join bagawk [0] (1000@bagawk.user) 05.59.08 Quit Leperkawn ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050511]") 06.13.50 Quit kenshin_ (Read error: 110 (Connection timed out)) 06.29.45 Quit bagawk ("Leaving") 06.43.13 Join cYmen_ [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 06.44.05 Quit cYmen (Read error: 104 (Connection reset by peer)) 06.53.03 Join ashridah [0] (ashridah@220-253-123-32.VIC.netspace.net.au) 07.03.01 Join ehntoo [0] (~noclue2@24-177-147-34.dhcp.mrqt.mi.charter.com) 07.39.12 Join gshgs [0] (patriarch@g228051.upc-g.chello.nl) 07.47.38 *** Saving seen data "./dancer.seen" 07.54.58 Quit Seed (Read error: 104 (Connection reset by peer)) 07.56.49 Join Harpy [0] (slkDk7tNlI@dsl-hkigw7wbb.dial.inet.fi) 07.59.14 Join Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il) 08.02.09 Quit Seed (Read error: 104 (Connection reset by peer)) 08.06.09 Join Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il) 08.06.34 Join tiegs [0] (~18e15776@labb.contactor.se) 08.07.10 Quit tiegs (Client Quit) 08.13.51 Join AEnertia [0] (~aenertia@210.54.152.120) 08.27.06 Join StrathAFK [0] (~mike@dgvlwinas01pool0-a204.wi.tds.net) 08.34.50 Quit Seed (Read error: 104 (Connection reset by peer)) 08.41.44 Join Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il) 08.45.08 Quit Thasp_ (Read error: 101 (Network is unreachable)) 08.51.24 Quit Strath (Read error: 110 (Connection timed out)) 08.56.29 Quit Harpy (Read error: 145 (Connection timed out)) 08.58.57 Quit gshgs (Read error: 110 (Connection timed out)) 09.03.31 Nick QT_ is now known as QT (as@area51.users.madwifi) 09.09.40 Nick StrathAFK is now known as Strath (~mike@dgvlwinas01pool0-a204.wi.tds.net) 09.26.54 Quit ehntoo ("Leaving") 09.32.39 Quit pabs (Read error: 60 (Operation timed out)) 09.47.40 *** Saving seen data "./dancer.seen" 10.08.56 Join einhirn [0] (Miranda@carlsberg.heim2.tu-clausthal.de) 10.13.55 Join Thasp [0] (Thasp@151.205.127.205) 10.21.40 Quit TCK (Read error: 104 (Connection reset by peer)) 10.30.34 Join webguest57 [0] (~d1ced0f8@labb.contactor.se) 10.31.16 # hello 10.32.42 # i have a question or rahter want your opinion 10.34.47 # what bmp wps do you think is the best\ 10.50.06 # amiconn: ofcourse it causes a spinup for every track, it needs a binary search to locate the runtime record for the track, and people didn't want the database in ram, also, it needs to save the runtime database whenever it changes, cause it has to happen before the unit will be powered off 10.51.16 # I know *why* it happens with the current design, however, you should try to find a way to do without it 10.51.33 # how? O.o. 10.51.34 # ...and *not* holding the whole db in RAM 10.51.53 # The current behaviour is inacceptable imho 10.52.21 # Rockbox tries to save as much battery as possible by prebuffering, and the runtime database destroys this concept 10.52.24 # well it could probably cache runtime data in the same way it buffers the audio 10.52.43 # ...and it is not even deactivatable if a valid tag database is found :( 10.53.22 # That's why I didn't further research the integration on archos although it seems that should be easy 10.53.28 # i have no idea how we would go around to caching the runtime info though 10.53.37 # maybe the runtime info can be added to the id3 info? 10.53.53 # Hmm, that sounds like a possible way 10.54.07 # iirc, on archos, it will still require it to save every time the data changes, cause it can shut down too fast? 10.54.35 # The playback code (playback.c on iriver, mpeg.c on archos) stores id3 info and associated data for a number of tracks 10.54.47 # mhm 10.55.00 # well, you'd just have to move the loading to that, i guess 10.55.27 # ...so the runtimedb code could put the runtime info into that (or even better imho, the playback code itself could update the runtime info field) 10.55.27 # but it would still need to write to the rundatabase every time so that data isn't lost before shutting dwon 10.55.31 # down 10.56.01 # ...and then call the function to update the runtime database (mutliple entries) when it is rebuffering 10.56.14 # ...or stopping 10.56.35 # wasn't there something with archos having a hardware turnoff thing? 10.56.48 # and rockbox not having time to do things before shutting down? 10.56.51 # or am i mistaken 10.56.51 # Yes, but you should ignore that 10.56.56 # why? 10.57.24 # There are 2 targets (archos player and recorder v1) which have a fast hardware shutdown (~ 1 sec) 10.57.33 # mk 10.57.45 # All others have a much longer delay, so we do software shutdown as on the iriver 10.57.55 # (rec fm, rec v2, ondiops) 10.57.59 # *ondios 10.58.20 # They still have a hardware shutdown, but that requires to hold the button > 10 seconds 10.58.24 # well, my suggestion is then to add all the info the runtime database needs about a file to the id3 tag thing 10.58.35 # Think of it as the archos equivalent of the iriver reset button 10.58.55 # like file entry info, current file entry offset, runtime info, current runtime entry offset.. 10.59.27 # The units with fast hardware shutdown also have a safe shutdown feature in rockbox, which takes care of flushing all info to disk 10.59.39 # k 10.59.49 # Hmm, on certain situations id3 structs might get cleared before actual buffer refilling 11.00.00 # ick 11.00.03 # why? 11.00.03 # We can't prevent the user from doing a hw shutdown, but if he does this, it is his own fault if some runtime info gets lost 11.00.51 # HCl: Also keep in mind that the hd spins up more often on archos due to the small RAM, so the potential loss isn't so big 11.00.58 # HCl: for example with dynamic playlists a flush event causes that behaviour (buffering code clears everything but the current track_info struct) and disk spinup will follow later 11.01.23 # ...and even on iriver there is a potential danger to loose some runtime data - when the battery gets too low 11.01.31 # * HCl is a bit confused, but isn't quite awake yet.. 11.01.35 # ...even with your current design 11.02.25 # then we could probably just have an array of structures containing that info for each song next to the track info thing? 11.03.06 # Slasheri: The important point would be to call the runtimedb callback *before* any such event processing, be it a normal buffer refill or a flush due to skip, new track selected etc 11.03.21 # amiconn: Hmm, that is possible 11.03.38 # Of course this menas the runtimedb code shouldn't take too long 11.03.40 # But i think the database should not flush to disk before the actual spin up is necessary 11.03.48 # it doesn't take long at the moment... 11.04.04 # the binary search is pretty fast, much faster than i had expected 11.04.11 # That's nice 11.04.46 # I tried to build a tagdb with your java songdb, however it seems this doesn't work with the runtimedb here (??) 11.05.02 # it should as long as the generated paths are okay 11.05.15 # they should start with a / and follow with the absolute path to a file 11.05.16 Quit webguest57 ("CGI:IRC (EOF)") 11.05.28 # you might need to grab the new songdb.jar from the wiki 11.05.29 # May that be caused by the fact that I ran it under windows? The paths are displayed with backslashes.... 11.05.40 # nah, i fixed that.. 11.05.45 # you probably have an oldish version 11.05.46 # I grabbed the latest one as of today ~1 am 11.05.49 # hrm 11.05.50 # odd 11.06.04 # Maybe I used --strip the wrong way? 11.06.08 # the slashes should be / and i *know* i fixed that o.o. 11.06.18 # i dunno 11.06.20 # i run it with.. 11.06.21 # Do I need to strip the drive letter? 11.06.38 # well, it does that for you, but if you have --strip, it should be added there 11.07.00 # Okay, perhaps I should try again... 11.07.12 # java -jar SongDB.jar C:\windows\profiles\hcl\desktop\music --strip c:\windows\profiles\hcl\desktop\music 11.07.15 # that worked fine here 11.07.29 # I prefer to run it directly on the unit 11.07.35 # yea, same 11.07.35 # I used 11.07.38 # that was just a test example 11.07.51 # java -jar L:\ --strip L:\ 11.07.51 # for my unit i use java -jar --dirisalbum / 11.08.00 # you can leave out the strip entirely 11.08.03 # Okay 11.08.07 # it will strip the drive letter by default 11.08.23 # The paths are printed with \ on the screen 11.08.33 # yea, thats okay 11.08.36 # as long as the final path 11.08.40 # in the end with longest filename 11.08.43 # is having / slashes 11.09.04 # its most probably the \ at the end of your strip 11.09.09 # removing the first / slash 11.09.20 # i haven't added code to force paths starting with / yet 11.09.21 # I think it would be better to print the mangled paths instead of the source paths, at least for tracking down problems 11.09.48 # (taking into account --strip, --add and \ ==> / replacement 11.09.48 # well.. the paths it shows are merely for showing, it doesn't process those since they are directories.. 11.09.53 # but okay 11.09.58 # Ah, yes 11.10.39 # I think it would still be better to show them processed as well. I might not be the only one who gets confused... 11.10.53 # yea, i'll change that and also force a / at the beginning.. 11.11.00 # I don't remember how the perl version does it 11.11.26 Join [IDC]Dragon [0] (~5483912e@labb.contactor.se) 11.11.57 # It *seemed* to me that the java version is slower, but I'm rather unsure about this 11.12.10 # (not the disk scanning step, but the sorting & output step) 11.12.17 # <[IDC]Dragon> hi there 11.12.32 # hi 11.12.36 # <[IDC]Dragon> before i gotta run off again: 11.12.52 # <[IDC]Dragon> i just made a BootBox wiki article 11.13.00 # <[IDC]Dragon> with .ucl files 11.13.08 # For testing? 11.13.13 # <[IDC]Dragon> yes 11.13.15 # I.e. flash as secondary? 11.13.21 # <[IDC]Dragon> yes again 11.13.23 # (with rockbox_flash) 11.13.39 # Ah 11.13.59 # Anything special to observe? 11.14.08 # <[IDC]Dragon> see the text 11.14.54 # You have tested on Ondio SP??? 11.15.17 # <[IDC]Dragon> FM, sorry 11.16.46 # uploading fixed version 11.16.55 # done 11.16.59 # <[IDC]Dragon> is there a way to delete a wrong attachment? so far I've hidden it. 11.17.16 # amiconn: try the new songdb.jar.. 11.18.37 # <[IDC]Dragon> btw, what is this dynamic db? 11.18.48 # [IDC]Dragon: Should I do that (I guess it's th eplayer .ajz)? 11.19.04 # proof-of-concept quality, at the moment, but it will keep track of playcount and other things 11.19.18 # in order to be able to do some nice searches on music 11.19.30 # <[IDC]Dragon> amiconn: or educate me how to delete 11.19.38 # There is no special delete action, to delete an attachment, you have to move it to the Trash web, topic TrashAttachment 11.20.18 # <[IDC]Dragon> how can I move it? 11.20.44 # Attach -> (attachment to delete) -> action -> move attachment -> To: Trash topic: TrashAttachment 11.20.46 # <[IDC]Dragon> ah, found it 11.22.08 # <[IDC]Dragon> thx 11.22.21 # HCl: Thanks. 11.22.27 # np 11.23.18 # HCl: Perhaps the runtime db should be switchable for now? 11.23.24 # <[IDC]Dragon> are all Rombox builds too big now (except Player)? 11.23.38 # (To avoid the spinup for those who want the tagdb, but not the runtimedb) 11.23.39 # amiconn: i would, but i'm not sure how to add a config option o.o 11.23.58 # [IDC]Dragon: Player and Ondio SP are still romboxable 11.23.59 # it shouldn't be hard to add, just a return -1 in the rundb_init depending on a variable 11.24.09 # HCl: I can do that 11.24.13 # please 11.24.34 # i could also use quite some help on moving the runtime data so that its pre-cached, since i have 0 experience with that 11.24.46 # <[IDC]Dragon> I've read about 2.5, is that prepared already? 11.24.56 Join hicks [0] (~hicks@zeus.mups.co.uk) 11.25.41 # HCl: Unfortunately I can't do that now, as I'm still busy with graphics... That requires much more work than a config option 11.25.43 # <[IDC]Dragon> sorry for my noob kindof questions these days 11.25.47 # thats okay 11.26.08 # the code isn't meant to be production quality yet, we needn't be in a hurry, the option to turn it off is a good idea though. 11.26.10 # [IDC]Dragon: The 2.5 snapshot is already taken (a week ago or two) 11.26.30 # i'm probably gonna look at getting the rating in the wps menu (?) that i haven't even discovered yet 11.26.32 Quit gromit` (Read error: 104 (Connection reset by peer)) 11.26.36 # <[IDC]Dragon> so I should check out that label for BootBox 11.26.37 # after i wake up 11.26.44 # and eat breakfast 11.27.19 # <[IDC]Dragon> must have happend secretly 11.27.35 Join Chamois [0] (~Chamois@i01v-62-35-66-23.d4.club-internet.fr) 11.27.39 Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) 11.27.46 # <[IDC]Dragon> so your latest gfx stuff is not in 11.29.29 Join PaulJ [0] (~PaulJ@vpn-3092.gwdg.de) 11.29.39 # <[IDC]Dragon> ok, I'm off and stop asking questions 11.29.54 # <[IDC]Dragon> ...will stop 11.29.58 # <[IDC]Dragon> cu 11.30.35 Quit [IDC]Dragon ("CGI:IRC") 11.31.06 # HCl: In 'General settings'->'Playback': 'Gather runtime data' yes/no 11.31.11 # Would that be acceptable 11.31.13 # ? 11.31.57 # sure 11.32.01 # sounds fine 11.32.02 # :) 11.32.25 # might want to add (experimental) to it for now 11.33.12 # Okay, will do that 11.33.27 # This is only the language string which is easily changed later 11.33.41 # * HCl goes to buy breakfast and stuff.. 11.33.44 # afk 11.47.43 *** Saving seen data "./dancer.seen" 11.52.01 Join preglow [0] (thomj@s183a.studby.ntnu.no) 11.52.45 # wassup 12.00.26 Quit PaulJ (Read error: 145 (Connection timed out)) 12.17.39 # HCl: When I'm thinking about it, caching the playtime info shouldn't need changes to the runtime db code, only to the playback code 12.17.56 # Well, almost 12.18.16 Join ep0ch [0] (~ep0ch@84.12.182.81) 12.18.33 # The playback code would the simply call the callback not after each track, but only when it is rebufferung, and then it would call it for all 'passed' tracks 12.18.56 # The id3 structure would then contain the actual playtime, which is a good thing imho 12.19.06 # No need to keep track of it in the database code 12.19.18 Join [-AIR-] [0] (air@host86-130-27-166.range86-130.btcentralplus.com) 12.19.23 Nick [-AIR-] is now known as west-acre (air@host86-130-27-166.range86-130.btcentralplus.com) 12.19.25 # mhm, you just have to move the data it requires to the id3 structure 12.19.42 # The data should already be there 12.19.47 # (I think) 12.20.00 # Hmm, that is a good idea 12.20.01 # There should be an additional parameter which would tell the runtimedb whether it should fsync() or not 12.20.13 # (To avoid fsyncing everytime) 12.20.18 # what do you mean the data should already be there? 12.20.21 # Before every flush that data from played tracks can be passed to the database 12.20.26 # This would then be true for the last call in each batch 12.20.28 # the runtime database requires quite a bit of knowledge 12.20.58 # The id3 structure contains path, length, and already played time 12.21.02 # it needs the offset of the fileentry of the file, the data that was in the file entry 12.21.11 # the offset of the runtime entry of the file 12.21.21 Join Moos [0] (MoosCamaro@m214.net81-66-158.noos.fr) 12.21.23 # the rating, playcount, and all the other runtime data 12.21.34 # and ofcourse the hashes of the runtime entry and the file entry 12.21.42 # Hmm, but this is handled by the runtimedb itself??? 12.22.00 # at the moment, yes, but there's only a single location where it stores this info 12.22.09 # so it would have to be moved to the id3 structure 12.22.15 # No, why? 12.22.49 # The way the runtimedb works won't change, the only thing that changes is the point in time when it is called 12.22.52 # because it would still require a harddisk spin up otherwise? 12.23.00 # No 12.23.05 # i'm confused. 12.23.12 # :/ 12.23.16 # Currently it is called after each track that finished playing 12.23.20 # yes. 12.23.45 # With the new concept it would be called by the playback code *when the playback code needs to rebuffer* 12.23.49 # you're wanting to keep track of the playcount, and look the file up when you're planning to write to it? 12.23.52 # ...which needs a spinup anyway 12.24.05 # in future it can be called n times for each track info in buffer while we have to rebuffer / erase the track structure 12.24.15 # ...and then it would be called *for all passed tracks* *in succession* 12.24.31 # you can't do that, since it loads runtime db info 12.24.35 # when needed 12.24.40 # Yes, and? 12.24.52 # you can't call it in succession cause the data wouldn't change 12.25.06 # * HCl is confused x.x 12.25.29 # the current code insists on getting called when a new song gets loaded 12.25.29 # Hmm? 12.25.33 # you can't call it at other locations 12.25.47 # prior to a song getting loaded it needs to load the runtime info of that song 12.25.52 # That would not happen 12.25.55 # Yes 12.26.08 # and at the end of it it needs to write the runtime info back after it has been altered 12.26.16 # Hmm, why would it need the runtime info prior to loading? 12.26.28 # because it contains stuff like rating, previous playcount, volume adjustment 12.26.37 # Imho it should be sufficient to do it all at the end (or even delayed further) 12.26.54 # no, we want playcount to be increased after 50% of the file has been played or so 12.26.59 # and volume adjustment to work, obviously 12.27.25 # Why would you require to increase playcount at the extact time 50% have passed? 12.27.37 # not exact, but 50% or 75% 12.27.41 # because at the moment its horrible 12.27.43 # even when you skip tracks 12.27.44 # It should be sufficient to bump playcount when we know that 50% have been played 12.27.46 # it still counts them as played 12.27.55 # yes 12.28.00 # ...no matter when that info is passed to the db 12.28.05 # but still. you NEED the info from the runtime database 12.28.18 # Okay, then this needs to be split in 2 12.28.19 # in order to be able to show playcount, change the rating properly and show the rating of the file 12.28.27 # and volume adjustment as well 12.28.33 # One callback would update all data for the passed tracks 12.28.48 # ...which would be called before rebuffering 12.28.59 # ...and another callback for upcoming tracks 12.29.10 # ...which would be called when buffering these tracks 12.29.23 # it would still be tricky, since you'd have to know which track is actually the current one 12.29.30 # and you'd have to store all the info in an array 12.29.42 # ...and the relevant playback info (which would be volume adjustment only) would then be stored in the id3 struct 12.29.54 # i prefer rating and playcount as well 12.29.56 # ...which already is in an array 12.29.58 # so you can actually show that on wps 12.30.05 # Yes, okay 12.30.25 # but yea, that would work 12.30.31 # as long as i can load the data into the id3 struct 12.30.37 # and fetch the data from the id3 struct to write it back 12.30.59 # Yes 12.31.22 # preferably by just calling a event_fetch_runtime_info(blah *id3) 12.31.23 # Imagine a rebuffer event: 3 tracks have passed, and 2 new one get buffered 12.31.32 # The following would happen: 12.31.34 # and an event_write_runtime_info(blah *id3) 12.31.50 # and just call that many times 12.32.09 # (spinup) -> call to runtimedb for passed track (3x) -> rebuffer -> call to runtimedb for upcoming track (2x) -> (spindown) 12.32.32 # sure 12.32.46 # as long as you use the two events i just described and i'm able to store the runtime data in the id3 tag 12.33.04 # yes, exactly 12.33.16 # preferably, i'd like to store the fileentry and rundbentry in the id3 as well 12.33.26 # I think this would work pretty well; the wps already accesses the info in the id3 struct 12.33.33 # it would prevent doing 2 binary searches when 1 will do 12.33.41 # How large are these? Just pointers? 12.33.45 # just ints 12.33.50 # Okay 12.33.52 # offsets into the databases 12.34.04 # Change that to explicit longs if possible 12.34.12 # yea, i think they are.. 12.34.16 # Fine 12.34.37 # hmm, or not *changes* 12.36.00 # We don't want to limit the databases to 64 KB on gmini, if that port will be finished some time, i think? ;) 12.36.18 # hm? are they limited to 64kb? 12.37.12 # If you use ints, then yes 12.37.16 # ah :P 12.37.18 # Gmini has a 16 bit cpu 12.37.23 # :P 12.37.35 # well, changed it, i'll go over the code later to see if i missed some 12.37.53 # Hmm. I do have that option prepared here, currently testing... 12.38.14 # Is there a method to display the runtimedb contents? 12.38.30 # a crude one... testdbv2.c in tools/ 12.38.41 # it requires you to set all the defines in the source to the values it spits out 12.38.46 # and recompile 12.38.49 # before it will work 12.38.51 # Hmm, my rockbox.rundb is still 8 bytes :( 12.39.05 # well, not much contents to display, then 12.39.07 # :x 12.39.16 # I did play a number of tracks... 12.39.20 # RRD1,0 is what it should contain 12.39.26 # did you turn the option thing on? 12.39.47 # the remote should print out some rundb info 12.40.03 # at the moment it ignores files with a hash of 0 12.40.22 # Yes I turned it on 12.40.30 # and it ignores files on which it fails to find a fileentry in the tagdatabase 12.40.52 # I have a database generated with your latest java songdb, which contains all files on my iriver 12.40.57 # k 12.41.13 # well, i guess you can toss me your database and i can check it briefly with testdbv2 12.41.27 # pretty much the thing you need to look for is whether the fileentries seem to have the correct path 12.41.43 # you could also add a logf to print out the results of the binary search 12.41.48 # I'll check whether the option is working 12.41.58 # (that's possible even without getting entries) 12.42.02 # Then commit it 12.42.46 # If I delete the rundb, the reboot, the file should be recreated when the option is on 12.42.53 # ...otherwise not 12.42.56 # mhm 12.44.10 # I also added proper handling for the usb case (like with the tagdb) 12.44.20 # thanks 12.45.59 # The volume adjustment has to be done by the playback code anyway, so the id3 struct should be the best place to keep it 12.46.12 # *nods* 12.47.25 # about time to start renaming the id3 struct, perhaps? :) 12.47.42 # It's called mp3entry now 12.47.49 # not much better 12.48.10 # doesn't matter much, but is misleading now that we support a bunch of codecs 12.49.26 # HCl: Committed. 12.49.27 Join Coldtoast [0] (edan@ppp110-115.lns1.hba1.internode.on.net) 12.49.32 # ...almost 12.50.57 # there. 12.53.01 # k :) 12.53.12 # * HCl needs more sleep :/ 12.53.32 # should i work on implementing those two event things when i'm awake? 12.53.44 # i just need someone to make the event interface much like the old one 12.54.13 # I think this would be cool 12.54.49 # mm? 12.55.17 # I mean, that it would not need to spinup after each track anymore 12.55.23 # *nods* 12.55.25 # I just have to find out why my database refuses to work, then I could add the event handling for archos 12.55.33 # k :) 12.55.47 # * HCl prods Slasheri a bi 12.55.48 # t 12.55.51 # I already tried, but I thought something was wrong because my runtimedb didn't get populated 12.56.19 # as long as the option is enabled and the tagdatabase is loaded, there are two options left to why it could go wrong 12.56.21 # Could be that just my tagdb was wrong... 12.56.24 # 1) the hash of the file is 0 12.56.28 # 2) the binary search failed 12.56.47 # the binary search fails if the tagdatabase has wrong filename entries 12.56.47 Join Christi-S [0] (~Christi@82-70-230-150.dsl.in-addr.zen.co.uk) 12.56.59 # Hmm. 12.57.06 # hi Christi 12.57.11 # Heya. 12.57.16 # * HCl goes to nap a bit :/ 12.57.21 # HCl: Hmm :) 12.57.30 # HCl: The has shouldn't be 0 with the java version, right? 12.57.31 Quit ep0ch ("goto") 12.57.41 # Slasheri: do you think you could implement the two events that were proposed? 12.57.51 # amiconn: nope, java version should be hashing 12.57.56 # you can try the testdbv2 tool 12.58.03 # it allows raw dumps of the database 12.58.09 # HCl: that doesn't sound a good thing. If you mean the start-of-track and end-of-track events? 12.58.19 # Perhaps I will... I have to decide between 4-grey coding and database adaption... 12.58.22 # :/ 12.58.28 # mmm, ask amiconn for details :/ 12.58.51 # Slasheri: No start-of-track and end-of-track when they actually happen 12.58.55 # i'm not 100% sure what i should call the events, but pretty much, there's one that gets called repeatedly for every id3 entry that needs to be saved 12.59.08 # and one that gets called repeatedly for every id3 entry that needs runtime info added to it 12.59.24 # * HCl goes for a nap now :/ 12.59.31 # amiconn: Hmm, only start-of-track and end-of-track when codec starts / ends? 12.59.33 # ...but 'upcoming track' for each track that gets buffered, and 'passed track' for each track that has passed, *at the time the rebuffering takes place* 12.59.57 # Ah 13.00.00 # ...to completey avoid additional spinups 13.00.14 # that might work 13.00.32 # I didn't look at how playback.c handles it, but I know a bit how mpeg.c handles it 13.00.40 # It should be quite simple 13.01.00 # so when we are buffering new tracks, generate an event when we start buffering a new track? 13.01.07 # mpeg.c has an array (16 entries) to keep info about all loaded tracks 13.01.32 # It has a read pointer and a write pointer and is used as a ring buffer 13.01.43 # currently playback.c generates the event at exact time (with audio buffer latency taken in account) when track change 13.01.46 # s 13.02.07 # The read pointer advances at each track change, and the write pointer advances advances for each newly buffered track 13.02.19 # yep, playback.c has that ring structure also 13.02.30 # For my proposal to work, we would need a third pointer, 'trailing read' 13.03.14 # The buffering code would call the 'new track' callback each time it advances the write pointer, which happens while buffering 13.03.44 # that sounds possible 13.03.53 # Immediately before buffering new tracks, it would count the 'trailing read' pointer up to the read pointer, and call the 'passed track' callback for each of these 13.04.34 # So n times callback for passed tracks, then rebuffer and call new track callback m times 13.04.36 # Hmm, is there a need for trailing read? I guess no because we know the buffered track count 13.04.46 # yes 13.05.07 # I don't know how playback.c does that, but the read pointer in mpeg.c advances at the time of a track change 13.05.18 # ..to keep track of current info for wps 13.05.38 # ...but we need to tell the runtimedb about all tracks that have passed 13.06.11 # yep, that is possible with the current implementation without any new pointers 13.06.24 # Okay, so you have 3 pointers? 13.06.57 # Or you keep track about the write position with th buffered tracks count? 13.06.58 # read_index, write_index and track_count. These are enough to find the passed tracks 13.07.08 # Ah, yes 13.07.44 Join Hansmaulwurf [0] (~maerlyn@p54AAE4CE.dip.t-dialin.net) 13.08.24 # i can implement that event :) 13.08.40 # mpeg.c does that a little different afair, but that shouldn't be a problem 13.09.02 # mpeg.c doesn't keep the track_count separately iirc 13.11.05 Quit ashridah (Read error: 110 (Connection timed out)) 13.11.21 # I think these 2 new event could be added while the current one should stay as well 13.11.35 # Then HCl could hook the runtimedb to these 2 new callbacks 13.11.40 # of course, i think it that way too :) 13.11.53 # ...and finally the current trackchange callback can go away 13.12.26 # The 'new track' callback should have an additional parameter 13.12.40 # ...telling the runtimedb whether this is the last call in the batch 13.12.54 Join ashridah [0] (ashridah@220-253-120-108.VIC.netspace.net.au) 13.12.56 # ah, ok 13.13.01 # This way it only needs to fsync() at the last call 13.13.40 # ...and the ata_sleep() in the playback code should go after these calls 13.13.42 Quit edx (Read error: 110 (Connection timed out)) 13.15.15 # sounds good :) 13.15.56 Join PaulJ [0] (~PaulJ@vpn-3061.gwdg.de) 13.18.14 Quit Christi-S ("If I were actually witty, this quitline would be funny.") 13.21.27 # Slasheri: Just a detail: It is perfectly possible that there are no callbacks at all when rebuffering, in case we're playing a very long track that was already running at the last rebuffer event, and will still play at the next rebuffer event 13.22.01 # Much less likely on iriver than on archos, but still possible even with mp3 13.22.11 # amiconn: yes, of course :) 13.22.19 # I had some 100 MB mp3 track.... 13.22.46 # callbacks will be called only when track really begins/ends 13.23.04 # And also, the 'new track' callback must be called at the initial buffer filling, and the 'passed track' callbacks at stop 13.23.27 # ...but I think you got the point :) 13.23.32 # yep :) 13.23.49 # i will try to test that these special cases works also 13.26.08 # How large is your track info array? 13.26.51 # On archos we use 16 even with the small RAM. Some users managed to exceed that, playing tiny snippets from a language learning CD... 13.27.29 # Hmm, i haven't measured it but it might be several thousands bytes long because we cache 10 id3 and mp3data structures. However, it should be enough to pass the mp3entry structure only to the database 13.27.32 Quit tvelocity ("Leaving") 13.27.52 # Yes, I mean the number of entries 13.27.55 # ...only 10 :/ 13.28.00 # Ah, yes 10 13.28.09 # That can be changed with the MAX_TRACK define 13.28.23 # easy... 13.28.32 # however, i have never had a situation that even 10 tracks in buffer at a time ;) 13.28.54 # I can imagine that happen with some albums I have 13.29.22 # ok, that number should be increased if necessary 13.30.53 # yup 13.31.23 # I just checked. D.Trance Gold CD1, encoded with lame @192 kbps 13.31.31 # The first 12 tracks are ~27 MB 13.33.55 # I noticed some strange effect with the backlight fading. It still flickers if there's a lot of bitmap drawing, but I don't understand why. 13.34.09 # Try snow.rock and logo.rock, you'll see what I mean... 13.35.14 # yes, i know that.. I think some interrupts might override the timer2 interrupt 13.36.36 # or maybe the interrupts are disabled while updating display 13.36.38 # Hmm, now I can't make it happen 13.36.57 # just try to write bunch of text to the remote lcd with logf 13.37.06 # that will cause that undesired effect always 13.37.35 # Ah, now I understand... 13.37.59 # It does happen with snow.rock and logo.rock, because these draw on the remote as well 13.38.07 # ...but only if the remote is plugged! 13.38.22 # :D so the problem is with the remote display code 13.38.35 # Rather, with the remote lcd data transfer 13.38.41 # yep 13.39.33 # Ahahhhh!!! 13.39.40 # I know why 13.39.48 # that's great :) 13.40.08 # The port handling of the remote lcd transfer interferes with the port handling in the backlight dimming interrupt 13.40.18 # oh 13.40.23 # That's tricky... 13.41.12 # That's because the port set/reset is non-atomic... 13.41.39 # * amiconn checks the coldfire manual 13.42.05 # We might need an equivalent to the SH1 read-modify-write AND and OR 13.43.36 # ..and it seems it is possible :) 13.43.51 # =) 13.44.16 Join Febs [0] (~chatzilla@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) 13.45.06 # That would be an equivalent to the and_b / or_b / xor_b macros for SH1 13.47.09 # The problem is that statements like GPIO1_OUT &= ~0x00000004; are non-atomic 13.47.46 *** Saving seen data "./dancer.seen" 13.48.13 # Hmm, yes. So it should be possible to make it atomic with some assembly code? 13.48.28 # so on archos, we have and_b(~0x04, &PADRL); as an equivalent (obviously for byte witdh only) 13.48.40 # This is actually a small assembly macro 13.48.50 # ...and that should be possible on coldfire as well 13.48.56 # good :) 13.49.32 # ...with something like and.l %dn,(%am) 13.50.31 # This has to be used for all port operations on ports that could be potentially changed in an interrupt as well 13.50.43 # ...which are practically all on iriver :/ 13.50.59 # Not too bad, but quite a number of changes 13.51.37 # That's true.. but if it's possible to do it with some nice macro it shouldn't be so bad 13.52.37 # Yeps. Look at firmware/export/system.h lines 82 ff how this is done for SH1 13.53.20 # We would then have and_l(), or_l() and xor_l() 13.53.22 # ah, that seems good :) 13.53.46 # ..even a bit more flexible since both the address and the data can be variables on coldfire 13.56.21 Join bipak [0] (~bip@p508848B1.dip.t-dialin.net) 14.00.50 # l 14.04.48 # w00t, that actually works :)) 14.05.04 # cool =) 14.05.39 # ..and it decreases code size a bit 14.05.49 # nice :D 14.13.23 # I converted the whole remote lcd driver and backlight.c for now. All other places doing port manipulation should probably be changed as well 14.14.24 Quit bipak_ (Read error: 110 (Connection timed out)) 14.19.02 # The flickering fade is no more :) 14.45.29 # any progress on the events thing or should i just go and look at implementing rating? 14.45.34 # how do i access the wps context menu? 14.47.24 # HCl: I will implement it soon (now working with mono playback) 14.47.34 # k :) 14.52.13 Quit Chamois ("Leaving") 14.55.02 Join edx [0] (edx@p54A8DAD5.dip.t-dialin.net) 14.58.49 # who can tell me about the wps menu? 15.00.29 # * HCl thinks he got it 15.04.13 Quit ze (Read error: 104 (Connection reset by peer)) 15.04.17 Join ze [0] (ze@ca-dstreet-cuda2-c9a-73.snbrca.adelphia.net) 15.14.41 # i'm bored :/ 15.15.00 # and i'm out 15.15.08 # see you guys some day in the not too distant future, i hope 15.15.14 Join tvelocity [0] (~tony@ipa201.6.tellas.gr) 15.15.21 # if i can stand 28k8 it might even be pretty soon! 15.15.22 # later! 15.15.26 Quit preglow ("leaving") 15.16.09 # cya.. 15.17.30 # * HCl prods amiconn 15.17.33 # any luck? 15.34.29 # Sorry, no. Didn't investigate further for now 15.34.34 # Gotta go, bbl 15.34.39 Part amiconn 15.36.22 Join xen` [0] (nop@stg25-1-82-238-117-1.fbx.proxad.net) 15.36.40 # Is there anyone on the .mod playing ? 15.36.54 Quit tvelocity ("Leaving") 15.36.55 # I'll probably take a look about if it's possible 15.37.16 # (if nobody on it) 15.47.49 *** Saving seen data "./dancer.seen" 15.58.59 Join tvelocity [0] (~tony@ipa201.6.tellas.gr) 15.59.10 # a ETA i antigrafi! 15.59.14 # :P 15.59.17 # mia wra* 15.59.19 # oops wrong channel 15.59.30 # damn xchat focus 15.59.33 Quit AEnertia (Client Quit) 16.07.49 Quit xen` (Read error: 145 (Connection timed out)) 16.14.29 Join kenshin [0] (~dave@c-24-17-8-193.hsd1.wa.comcast.net) 16.19.10 # anyone know when t0mas will be back? 17.22.13 Join Godeater [0] (~c2cbc979@labb.contactor.se) 17.23.33 Quit Godeater (Client Quit) 17.29.15 Quit tvelocity ("Leaving") 17.37.27 Join DangerousDan [0] (~Miranda@194.22.60.59) 17.39.42 Quit kenshin (Read error: 110 (Connection timed out)) 17.47.53 *** Saving seen data "./dancer.seen" 17.48.03 # mrf 17.48.06 # * HCl prods around 17.48.14 # Slasheri / amiconn? 17.49.10 # HCl: you will get it soon :) 17.50.49 Join bagawk [0] (1000@bagawk.user) 17.51.35 Join pabs [0] (~pabs@xor.pablotron.org) 17.52.21 # k :) 17.52.26 # * HCl is falling asleep here 18.04.36 Join muesli- [0] (muesli_tv@Bbc99.b.pppool.de) 18.09.56 Join courtc [0] (~courtc@adsl-154-38-44.asm.bellsouth.net) 18.13.19 Quit edx () 18.18.21 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 18.19.12 Join kenshin [0] (~dave@c-24-17-8-193.hsd1.wa.comcast.net) 18.19.43 Join Lost-ash [0] (ashridah@220-253-122-74.VIC.netspace.net.au) 18.22.42 Quit ashridah (Read error: 110 (Connection timed out)) 18.23.44 Quit hicks (Remote closed the connection) 18.24.07 Quit muesli- ("ich will Kühe!!!") 18.26.25 Join hicks [0] (~hicks@zeus.mups.co.uk) 18.34.19 # HCl: Done, now testing 18.36.20 Nick Lost-ash is now known as ashridah (ashridah@220-253-122-74.VIC.netspace.net.au) 18.36.34 Quit ashridah ("Leaving") 18.39.21 Join webguest91 [0] (~d49f4cf2@labb.contactor.se) 18.41.41 Join XavierGr [0] (~test@ppp13-adsl-95.ath.forthnet.gr) 18.49.48 # HCl: it should work now, i will commit 18.51.45 # does anyone know what HAVE_LCD_CHARCELLS define means? 18.53.36 Quit bagawk ("Leaving") 18.55.06 Join amiconn [0] (jens@pD9F4C491.dip.t-dialin.net) 18.57.24 # hi amiconn 18.57.41 # hi 18.58.48 # amiconn: I see that while there are scroll configuration variables in lcd-h100-remote.c there are not present to configure in settings.c and settings-menu.c 18.58.58 # Yes 18.59.30 # I tried to add them but I got lost... 18.59.31 # Nobody did this so far because the remote isn't really used with scrolling yet 19.00.34 # does anyone know what HAVE_LCD_CHARCELLS define means? 19.00.37 # There is some oddity too which I don't understand why Rick did it 19.00.58 # The remote scrolling thread isn't created for the simulator. Imho it should 19.01.31 # Yes, that's simple, and should be obvious. It means the target has a character cell based display, as opposed to bitmap based 19.01.31 # yeah all my attempts to test code is making a normal build to test in my player it is very tiresome 19.01.58 # like seven segment displays? 19.02.16 # The only device that has this is the archos player/studio 19.02.23 # oh I got it 19.02.33 # It has a 2 line x 11 character, 5x7 point dot matrix display 19.02.55 # However, you can't freely access the single dots 19.03.32 # The display ram contains character values, and the 5x7 dot matrices are taken from a character generator, which is mostly in ROM 19.03.42 # so player/studio is very limited in text output I guess... 19.03.46 # Yup 19.04.08 # It's still possible to support many rockbox features on that limited display 19.04.38 # Depending on the exact lcd type (there are old and new players), 4 or 8 characters are user definable 19.05.25 # This is what the playergfx library exploits - it allows (tiny) bitmap grahpics on this display! 19.07.26 # so what about the remote thread you proposed. Do you think that it will have files like remote-wps.c and remote-tree.c e.t.c 19.07.38 # or it will be implemented in current code? 19.11.01 # any plans for the remote uisimulator on win32 yet? 19.11.55 Quit DangerousDan (Read error: 131 (Connection reset by peer)) 19.12.41 Join Ancelot [0] (Ancelot@42-138-126-200.fibertel.com.ar) 19.12.59 # Bagder 19.13.15 # BADGER BADGER BADGER BADGER BADGER BADGER BADGER BADGER BADGER BADGER BADGER (mushrooom mushrooom!) 19.16.09 Join Stryke` [0] (~Chairman8@cpe-24-168-110-99.si.res.rr.com) 19.16.45 Quit Ancelot (Client Quit) 19.27.41 Quit amiconn (Read error: 110 (Connection timed out)) 19.32.17 Join amiconn [0] (jens@pD9F4C759.dip.t-dialin.net) 19.35.20 Join road_runner [0] (~5540763e@labb.contactor.se) 19.36.37 # Question: I found something very useful at sourceforge and there's no apperent reason why RockBox wouldn't include that patch on their build. where's the place to suggest to use it? 19.37.21 # well, there is some patch-area at rockbox.org i think 19.38.36 # thanks i'll check it out. 19.38.37 # link? 19.40.48 Quit Stryke` ("Friends don't let friends listen to Anti-Flag") 19.40.55 Join Stryke` [0] (~Chairman8@cpe-24-168-110-99.si.res.rr.com) 19.47.39 Quit courtc (Read error: 110 (Connection timed out)) 19.47.57 *** Saving seen data "./dancer.seen" 19.48.27 Join courtc [0] (~courtc@adsl-158-49-201.asm.bellsouth.net) 19.48.59 Part amiconn 19.56.02 Quit Stryke` (Read error: 145 (Connection timed out)) 20.08.35 Quit XavierGr () 20.13.49 Join Bger_cgiirc [0] (~d5f0dcba@labb.contactor.se) 20.14.24 # Bagder / B4gder : about Li-Ion batteries... it seems you 20.14.29 # are right 20.14.48 # http://www.computerhope.com/battery.htm#02 20.14.57 # http://www.batterieswholesale.com/damaging_batteries.htm 20.15.04 # http://wirelessreview.com/mag/wireless_power_liion/ 20.15.47 # some quotes 20.15.50 # "Another easy way to destroy an Li-Ion battery is by discharging it too far." 20.16.06 # "The Li-Ion cell should never be allowed to drop below about 2.4V, or an internal chemical reaction will occur where one of the battery electrodes can oxidize (corrode) through a process which can not be reversed by recharging." 20.16.43 # "The Li-Ion typically is discharged to 3V/cell. The lowest low-voltage power cutoff is 2.5V/cell." 20.17.05 # "During prolonged storage, however, a discharge below this voltage level is possible. Manufacturers recommend a trickle charge to raise such a battery gradually back up into the acceptable voltage window. Not all chargers are designed to apply a charge once a Li-Ion battery has dipped below 2.5V/cell." 20.17.11 Quit Hansmaulwurf ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 20.18.11 # sorry for the flood... 20.26.09 Join CheeseBurgerMan [0] (~Dan@63.150.80.210) 20.30.58 # http://www.national.com/appinfo/power/files/f19.pdf 20.38.01 Join Yokaloshi [0] (~Yokalosh@cpc1-cbly2-4-0-cust103.glfd.cable.ntl.com) 20.38.51 Join PaulJ_ [0] (~PaulJ@vpn-3048.gwdg.de) 20.39.01 # guys, since #linux + #debian are totally useless i have come seeking someones advice cos u ppl are in the know..... 20.39.15 # which version of debian should be used with an amd-k6?: [alpha] [arm] [hppa] [i386] [ia64] [m68k] [mips] [mipsel] [powerpc] [sparc] 20.40.17 # or am i wrong and none of you have the slightest idea? 20.41.59 Quit CheeseBurgerMan (Client Quit) 20.42.56 # anyone? 20.42.59 # no-one? 20.47.45 Join CheeseBurgerMan [0] (~Dan@63.150.80.210) 20.47.58 # yokaloshi: i386 20.49.55 Quit hicks (Remote closed the connection) 20.51.23 # thanks 20.51.26 # what kernal? 20.51.43 # just use the latest unstable or stable version 20.51.49 # oki doki 20.51.51 # And always newest kernel, 2.6.xx should be ok 20.52.14 # 2.6 on the debian disk didnt work 20.52.19 # i'll try something older 20.52.22 Join hicks [0] (~hicks@zeus.mups.co.uk) 20.52.35 Quit west-acre ("—I-n-v-i-s-i-o-n— 2.0 Build 3515") 20.54.11 Quit Yokaloshi () 20.55.17 Quit PaulJ (Read error: 113 (No route to host)) 20.59.41 # Hmm, the voice ui seems quite easy to port 21.01.57 # Hi Slasheri, not needed a new codec like speex? 21.13.44 # Moos: We can implement the new codec later. If i understood correctly we should modify the codec loader to support two codecs loaded at a time 21.14.05 # So we could have the voice codec always loaded & ready 21.16.09 # a ok, goody :) 21.17.19 # hm, what do you think about the idea to put rockbox.iriver in .rockbox folder ? 21.17.33 # in *the* rockbox folder... 21.18.02 # i know that it's a must for the archos devices to be in the root folder 21.19.07 # but this comes from being compatible with original archos firmware 21.20.02 # however, iriver's firmware never had posibility to load the firmware from the disk 21.22.23 # yes, i know that for making such change it's needed to change the bootloader 21.31.16 Quit Thasp () 21.48.00 *** Saving seen data "./dancer.seen" 21.48.46 # Imho, would clean up some mess, not having files running around at your Root folder. specially when it's out in the public. 21.50.30 # yes, that's my reason to offer this 21.55.33 # um its only one file... 21.57.06 Quit kenshin (Read error: 145 (Connection timed out)) 21.57.42 # but don't you think that all rockbox specific stuff is good to be in the .rockbox directory ? 21.59.13 # Either that or modify the rockbox file list to hide rockbox.iriver when normally viewing 22.01.15 # hicks, when you hide it, it's still there 22.02.36 # yes, but is there a major problem with it been there if you can't see it? kinda like the .rockbox folder is there but not visible? 22.04.13 # That's just a part of the problem. the other is you don't want no one to exidently delete the file. if it's inside a directory it's less likely to happend. 22.04.13 # not the same when you attach the unit to a PC 22.04.29 # yeah thats true 22.04.39 # (accidently) 22.04.56 # this too 22.07.00 Quit road_runner ("CGI:IRC (EOF)") 22.23.55 # nite 22.23.58 Quit Bger_cgiirc ("CGI:IRC 0.5.4 (2004/01/29)") 23.02.12 Quit Febs ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050511]") 23.02.34 Join stoffel [0] (~sfr@dsl-084-057-136-155.arcor-ip.net) 23.07.02 Join Musicmad [0] (~Musicmad@port547.ds1-oebr.adsl.cybercity.dk) 23.07.02 Join PaulJ [0] (~PaulJ@vpn-3048.gwdg.de) 23.09.31 # I found a workaround for that 'Next track' not displaying bug 23.10.03 # Someone suggested using t0; in front which forces a refresh to display after buffering 23.10.08 Join noel_sad_sogn [0] (~c87ec44a@labb.contactor.se) 23.11.10 # Hey.... anybody there? 23.11.11 # I don't see why wps can't pull the ID3 tag info without having to buffer the next track first 23.11.24 # Rori: then write a patch 23.11.30 # :) 23.11.37 # Show me how ;) 23.11.46 # that's your fave response Bagder :_ 23.11.47 # questioning functions when you don't know how things work is odd 23.11.54 # I'm not complaining just pointing it out heh 23.12.04 # Coldtoast: yes it is! ;-) 23.12.13 # hehe 23.12.21 # Rori: of course we would've done that if it was that simple 23.12.42 # I look from laymans point of view. If there is a technical reason not much else I can do or say as long as someone tells me that is the reason 23.12.58 # well _everything_ more or less is possible 23.13.05 # given enough time and sweat 23.13.09 # of course 23.13.21 # where's the ID3 info stored in an MP3? 23.13.23 # but some things have limitations due to hardware 23.13.33 # Coldtoast: in the begining or the end of the file 23.13.51 # beginning OR end? how odd 23.13.59 # v1 vs v2 id3 23.14.02 # so you have to read the entire file to read the tags? 23.14.07 # beginning or end depending on what version of ID3 it is I assume? 23.14.07 # no 23.14.07 Join kenshin [0] (~dave@c-24-17-8-193.hsd1.wa.comcast.net) 23.14.11 # you can seek to the end 23.14.17 # Coldtoast: yes 23.14.25 # ok 23.15.49 # Does it seem like every time I type something here it's a whinge? If so I apologise. I'm just speaking my mind without knowing much really. 23.16.15 # Take it with a pinch of salt ;) 23.16.18 # you say things "I don't see why..." 23.16.28 # which sounds as if you question things 23.16.59 # at least in my ears 23.17.00 # Well I don't because I don't know much so I say it without actually asking directly. Maybe I should just ask instead of putting it in such a way as it seems like a whinge :) 23.17.36 # think I'll go watch War of the Worlds when I wake up 23.17.45 # Nothing wrong with questioning things. But I guess it is how it comes across that counts. 23.17.50 # I saw it 23.17.54 # well half of it 23.18.04 # I was in the loo puking up a lot whilst at the cinema 23.18.13 # is it THAT bad?!? 23.18.17 # something I ate did not agree with me 23.18.19 # lol 23.18.24 # :) 23.18.25 # yeah it was THAT bad ;) 23.18.38 # I saw Tom Cruise' acting and it made me vomit 23.18.46 # I actually like Tom now 23.18.56 # It was an OK movie from what I saw of it 23.19.17 # never really used to but he's done some films I LOVE in recent years; Minority Report, Vanilla Sky, Last Samurai 23.19.26 # was lacking a little from a modern day spin on the story I thought. It stuck too close to the book which is a bit out of date now. 23.19.41 # But the fighting machines were awesome! 23.19.46 # then I saw the full vid of the guy squirting him and how he reacted and I now really like him 23.20.09 # and the sound they make will make you shat your pants 23.20.19 # nuff said 23.20.24 # enjoy 23.20.29 # hope so 23.20.43 # not expecting it to be as enjoyable as Batman Begins but I hope I like it 23.20.52 # it's enjoyable 23.20.55 # Batman Begins is absolutely AWESOME 23.21.06 # don't try to look too close at the plotholes 23.21.28 # Batman Begins had some plotholes but I looked past them 23.21.41 # Because the acting and ideas in it were great 23.22.17 # tiem to get my player and update it 23.22.22 # I want to see wotw again to catch the bits I missed while in the toilet chucking my guts up 23.22.34 # downloading a cam 23.22.43 # I think I have that right since I paid to see it anyhow ;) 23.22.58 # and it will get deleted afterwards since the quality sucks 23.23.18 # I will just flick to the bits I missed 23.23.54 # eh... no comment 23.25.21 Quit PaulJ_ (Read error: 110 (Connection timed out)) 23.28.47 # there's still a prob with mono MP3s 23.29.12 # I get L+R fine, which is gret, but I also get a constant ticking thru them 23.29.43 # Bagder: if you play that MP3 I found from the other day, you should hear it 23.30.38 # aaah 23.30.40 # hold on 23.30.55 # it's the resampling I guess. the ones that tick are 22KHz 23.31.24 # the 64kbit, 44.1KHz ones are clean 23.39.01 Quit Bagder ("Off to search for that connect-resetting peer guy!") 23.40.02 Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 23.42.52 # hmmm ... the simulators seem to mess up the gnome control panel ... thats weird :) 23.43.03 # ? 23.43.08 # not for me 23.43.19 # it doesn't do it every time 23.43.26 Join ghostiger [0] (~ghostiger@fdf84575d351d3c3.session.tor) 23.43.26 # it never did it for me 23.43.34 # it just happened twice since i've used it... really weird 23.43.37 # and I've used the sim on x11 since day 1 23.43.47 # the panel vibrates and cpu usage sky rockets 23.43.47 # (day 1 the sim existed that is) 23.43.55 # killall gnome-panel fixes it ... 23.44.13 # I say that is a bug in gnome then 23.44.19 # possible :p 23.44.36 # the sim uses only plain x11 functions 23.47.04 Quit noel_sad_sogn ("CGI:IRC (EOF)") 23.48.01 *** Saving seen data "./dancer.seen" 23.48.36 # * Bagder just made a little alsa app that says "glitch" 23.49.52 # hey Bagder: how do you disable a soundcard in Linux? 23.50.06 # I have 2 in this machine and need to disable one cos PCM gets sent to the wrong one 23.50.20 # unload its module? 23.50.20 # unload the driver for it 23.50.21 # Coldtoast: you can try rmmod 23.50.44 # I did try using the hotplug blacklist but it stopped working] 23.50.48 # ok 23.51.12 Quit PaulJ (Remote closed the connection) 23.51.18 # by "stopped working" I mean it stopped beign disabled. Something must have been calling the driver 23.51.22 # also, the card is often identified by an alias in /etc/modules.conf that could be changed 23.51.39 # ok 23.51.59 # I have a good reason for hacing 2 cards, btw 23.52.00 # but I'm not really skilled in linux sound 23.52.16 # one's my pro card which I need for ASIO. the other's an Audigy 2 23.52.23 # Coldtoast: you blacklisted it in /etc/hotplug/blacklist.d/ ? (works fine here) 23.52.32 # I use the pro card for recording guitar and the Audigy 2 for gaming 23.53.08 # is there another blacklist file in that die dionoea? 23.53.27 # "in that die" ? 23.53.37 # err. die=dir 23.53.53 # well ... you can put as many files as you wish 23.54.06 # they all get parsed when hotplug is launched 23.54.17 # in /etc/hotplug/ is there a file called "blacklist"? 23.54.31 # that was the old way of doing it i think 23.54.43 # but its there all right 23.54.44 # aah. then I was doing it the old way 23.54.53 # yeah. that may be why it doesn;t work too well 23.54.55 Join muffti [0] (~5495d9b8@labb.contactor.se) 23.54.55 # what distro are you using ? 23.55.00 # Mandriva 23.55.01 # hi 23.55.46 # hey 23.56.06 # i need some help installing rockbox 23.58.08 # muffti: http://www.rockbox.org/twiki/bin/view/Main/IriverBoot 23.58.49 # i've got a archos jukebox studio 10 23.58.55 # OH