--- Log for 13.01.109 Server: niven.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 month and 5 days ago 00.01.00 Join ShadowGazer [0] (n=ShadowGa@c-68-61-167-112.hsd1.mi.comcast.net) 00.03.14 Join solexx [0] (n=jrschulz@e176115229.adsl.alicedsl.de) 00.05.45 Join troy__ [0] (n=toppy@92.24.21.252) 00.11.42 # I'm trying to install RB on a sansa e280 version 1. When I run the utility it does not recognize my sansa. I made sure it was a version 1 before I bought it. Can anyone give me any ideas? 00.12.58 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-49d8094fa998480d) 00.13.08 Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) 00.13.20 # ShadowGazer, double-check and make sure the OF version is indeed 01.x.x 00.13.50 # I did 00.14.07 # are you running the utility with root/administrator permissions? 00.14.12 # Yes 00.14.58 # it's version 01.02.24A to be exact 00.17.12 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/session) 00.17.52 Quit archivator (""Pass midnight here"") 00.18.46 Quit solexx_ (Read error: 110 (Connection timed out)) 00.20.34 Quit tyfoo ("Carpe diem") 00.20.56 Quit Zagor ("Clint excited") 00.21.35 # a manual install makes it so it reboots like it's installing but it doesn't install...it just goes back to the sansa startup screen then starts up normally 00.23.14 Quit troy_ (Read error: 110 (Connection timed out)) 00.25.26 Quit ender` (" I like work: it fascinates me. I can sit and look at it for hours. -- Jerome K. Jerome") 00.25.27 # I'm gonna try a computer reboot see if that makes any difference 00.25.33 Quit ShadowGazer () 00.27.32 Join Genbu [0] (n=Byakko@207.62.156.219) 00.29.49 # need korean text support help! 00.30.11 # Genbu: which font are you using? 00.30.21 # how do i check? 00.31.04 Quit Schmogel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 00.31.42 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 00.33.07 # rasher:? 00.33.33 # Genbu: Check the theme you're using, I guess 00.34.06 # Genbu: also, did you install the font package? 00.34.16 # yeah i did 00.34.23 # i got a lot of fonts on here 00.35.05 # which theme do you use and which player do you have exactly? 00.35.28 # i'm using GreyScaleVP on RockBox iPod 4G Grey 00.40.43 # looks like this one is using a 13 pixels tall font - http://www.rockbox.org/twiki/bin/view/Main/UnicodeFonts suggests that "13-Fixed" is a same-sized alternativewith korean support 00.41.21 # will that support all east-asian? 00.41.33 # cuz i dont wanna lose my japanese support either 00.41.39 # i really wish there were a nice, open vector unicode font from which to generate our unicode fonts 00.42.13 # Genbu: did you have a look at the table in the wiki I linked too? 00.42.17 # s/too/to 00.42.24 # woops didnt see it 00.44.53 # you could also try different themes which already use one of the more "complete" fonts. I think UniCatcher should be available for you 00.45.19 # i like the look of GreyVP tho XD 00.45.32 # Fixed will have to do even if the periods and colons look ick 00.46.05 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 00.46.51 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-209e1738fddb44ae) 00.48.52 Quit t0mas ("good night!") 00.49.25 # Genbu: http://rasher.dk/rockbox/fontstats/ has more complete (and confusing) information about fonts and character coverage 00.49.35 # yeah i saw that 00.51.53 Quit mcuelenaere () 00.52.30 # haha wow fixed is missing some other extended characters that some of my titles have 00.52.32 # crud. 00.52.33 # :( 00.53.04 # you could add them! 00.54.00 *** Saving seen data "./dancer.seen" 00.54.28 # how so? 00.55.20 Quit Thundercloud (Remote closed the connection) 00.56.07 Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) 00.56.50 Join Schmogel [0] (n=Miranda@essn-4db6c583.pool.einsundeins.de) 00.57.48 Quit Schmogel (Client Quit) 00.59.06 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 00.59.07 Quit kugel ("ChatZilla 0.9.84-rdmsoft [XULRunner 1.9.0.5/2008121622]") 01.02.02 # Genbu: With a font editor 01.02.20 # i dont have one, any suggestions? 01.02.43 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 01.03.01 Quit massiveH (Client Quit) 01.03.40 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 01.05.09 Quit saratoga ("CGI:IRC (EOF)") 01.07.39 # Genbu: gbdfed or Fontforge on Linux, no idea about Windows. 01.08.33 # i could run one of those in my xVM 01.08.37 # i guess 01.14.13 Quit PaulJam (".") 01.17.04 Quit jgarvey ("Leaving") 01.19.28 Join troy_ [0] (n=toppy@78.146.244.178) 01.20.25 # amiconn: you still up? 01.20.57 Quit tessarakt ("Client exiting") 01.21.40 Quit Nico_P (Remote closed the connection) 01.22.45 # incase you read this... and so i dont forget.... any ideas why lcd_getstringsize() is called in mpeg.c (line 875+), its ret val is ignored and both w and h are passed as NULL... 01.25.52 # markun actually did that change back in dec 05! (r8184) 01.26.20 Quit robin0800 (Connection timed out) 01.26.59 Join robin0800 [0] (n=quassel@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 01.27.34 Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 01.27.41 # I guess its just to make sure the glyphs are loaded.. seems an odd place to be doing it though 01.29.14 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-55a28e9a426c599d) 01.31.25 Quit troy__ (Read error: 110 (Connection timed out)) 01.40.26 Part toffe82 01.47.55 Join ShadowGazer [0] (n=ShadowGa@c-68-61-167-112.hsd1.mi.comcast.net) 01.48.23 # Is there any place I can get Rockbox 3.0? 3.1 doesn't seem to detect my player and I want to try 3.0 to see if that might work 01.50.25 Quit timc`` (Connection timed out) 01.51.10 Join timc`` [0] (n=aoeu@116.3.2.205) 01.52.13 # nevermind, I found it and it works 01.52.18 Quit ShadowGazer (Client Quit) 01.54.36 # * linuxstb wonders what ShadowGazer was talking about 01.57.52 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 02.02.02 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 02.06.04 Part Aurix_Lexico 02.07.11 Quit Thundercloud (Remote closed the connection) 02.07.24 Join aurix_lexic1 [0] (n=adam@c-68-56-205-239.hsd1.fl.comcast.net) 02.11.02 Quit bobsalad (Connection timed out) 02.18.36 Part massiveH ("Leaving") 02.21.11 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 02.23.04 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-d3b19a0f6121166d) 02.23.54 Quit troy_ (Read error: 104 (Connection reset by peer)) 02.25.42 Join blkhawk- [0] (i=HydraIRC@g228005213.adsl.alicedsl.de) 02.26.44 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 02.27.49 # anyone with a hwcodec player and a few min to test out a patch? 02.33.09 # scorche: ^? 02.41.57 Join __lifeless [0] (n=lifeless@90.151.215.203) 02.42.27 Quit _lifeless (Read error: 113 (No route to host)) 02.43.22 Quit blkhawk (Read error: 113 (No route to host)) 02.50.23 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 02.54.02 *** Saving seen data "./dancer.seen" 02.54.36 Join MarcGuay [0] (n=chatzill@ip216-239-85-253.vif.net) 02.55.07 # * MarcGuay guesses that ShadowGazer was talking about RB util... 02.59.58 Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) 03.09.39 Join toffe82 [0] (n=chatzill@adsl-76-240-239-184.dsl.frs2ca.sbcglobal.net) 03.10.06 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 03.16.54 Quit Rob2222 (Read error: 110 (Connection timed out)) 03.19.02 Join shodanX_ [0] (n=shodanX@port-92-194-55-107.dynamic.qsc.de) 03.20.43 Quit shodanX (Read error: 60 (Operation timed out)) 03.29.03 Quit Makuseru (Read error: 104 (Connection reset by peer)) 03.33.28 Quit fyrestorm ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 03.44.25 Join CaptainKewl [0] (n=jason@cpe-68-173-40-122.nyc.res.rr.com) 03.45.50 Join Davide-NYC [0] (n=Davide-N@user-12ld9li.cable.mindspring.com) 03.46.46 # MarcGuay: did you ever get your gigabeat S sorted? 03.47.14 # Davide-NYC: Nope. All updater softs crash when I run with it connected. 03.47.36 # I think it's an MTP problem and haven't tried on another PC yet. Did you simply run the 1.2 updater? 03.49.12 Join gromit`` [0] (n=gromit@ALagny-154-1-6-203.w83-112.abo.wanadoo.fr) 03.54.31 Join FlynDice [0] (n=jack@c-24-19-225-90.hsd1.wa.comcast.net) 03.54.43 # how can i find out if a target player uses the swcodec? 03.55.42 # You mean a current target, or a new player you're investigating? 03.55.53 # a new player 03.56.18 # Really, I would assume you're looking for two things 03.56.41 # If it's hardware codec there will be some dedicated hardware. 03.56.57 # If it's software codec, there will be actual code in the firmware for playing the supported codecs. 03.57.25 # thanks 03.57.26 # Odds are very high any modern player (or really, most players that support more than PCM + MP3) are what we call software codec 04.00.28 Quit gromit` (Connection timed out) 04.08.50 # MarcGuay: yeah, but first I uninstalled libusb 04.12.18 # Davide-NYC: Windows? 04.12.24 # yes 04.12.35 # I had a libusb device installed. 04.13.57 Quit parafin (Read error: 60 (Operation timed out)) 04.16.34 Join parafin [0] (i=parafin@paraf.in) 04.20.32 # MarcGuay: did you try with a dual boot bootloader? 04.27.01 Quit Aurix_Lexico ("Leaving.") 04.28.34 Quit robin0800 (Read error: 104 (Connection reset by peer)) 04.29.11 Join Rob2222 [0] (n=Miranda@p4FDCC4A4.dip.t-dialin.net) 04.30.29 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 04.39.11 Quit midkay ("Leaving") 04.40.28 # Davide-NYC: I was running an old bootloader from months ago before trying the single-boot the other day. 04.41.28 # have you tried a dual-boot of recent vintage? 04.42.43 Join Barahir_ [0] (n=jonathan@Ya01a.y.pppool.de) 04.42.59 # Davide-NYC: Nope, can't even recover the OF right now. Other people have reported success with both singles and duals from recent day's builds, though.. 04.43.24 # Don't take that as an endorsement, of course. 04.44.08 Quit Barahir (Read error: 60 (Operation timed out)) 04.44.08 # hmm. So what do we think causes this problem? Do you think the pre-bootloader (not sure what it's official name is) is modified by the update? 04.44.23 Join steerpike [0] (n=Unknown@unaffiliated/steerpike) 04.44.29 # Or is this problem indipendant of the v1.2 update? 04.44.33 # hi :) 04.45.28 # Davide-NYC: I was running an old OF when I updated. 04.45.35 # ... the rockbox bootloader... 04.46.32 # can these run rockbox? http://tinyurl.com/9o8bf5 04.47.17 # steerpike: http://www.rockbox.org/twiki/bin/view/Main/TargetStatus 04.47.21 # steerpike: the targets that rockbox runs on are listed on the front page 04.47.46 # Davide-NYC: www.rockbox.org is a much simpler and easier to read link/list ;) 04.48.22 # steerpike: scorche is correct: www.rockbox.org 04.48.37 # how do I compile mknkboot in cygwin? 04.48.52 # so chinese ipod touch knock offs are out of the question? :\ 04.49.11 Join allele [0] (n=allele@CPE-69-23-137-242.wi.res.rr.com) 04.49.17 # steerpike: are they on that list? 04.49.21 # Davide-NYC: Find the directory it's in and type "make"? 04.49.26 # i don't even know what the brand is 04.49.28 # is there a random() function built into rockbox? 04.50.02 # steerpike: The answer is no. 04.50.10 # MarcGuay: there are several files in that dir. Do I type "make mknkboot"? 04.50.52 Quit aurix_lexic1 ("Leaving.") 04.50.54 # Davide-NYC: Is it in tools? 04.50.59 # yes 04.54.03 *** Saving seen data "./dancer.seen" 04.55.01 # allele: it provides a rand and srand, but the rand is a fairly good PRNG, and not any of the various LCGs which are often behind rand() 04.55.25 Join blkhawk [0] (i=HydraIRC@f051067222.adsl.alicedsl.de) 04.55.47 # Davide-NYC: Sorry I can't help. 04.56.02 Quit blkhawk- (Read error: 60 (Operation timed out)) 04.56.31 # I believe I may have it 04.57.19 # My more-often-used dual-boot builder mktccboot is pre-built. 05.00.01 Quit allele ("Java user signed off") 05.05.08 # I may have thoroughly messed up my beast now 05.05.13 # Hahaha 05.05.45 # Davide-NYC: Join me, my son. 05.06.52 # LOL. What I have now is a single-boot (to the OF) dual-boot bootloader that just "hangs" at the white windows mobile screen unless I have the hold switch in the "hold" position. 05.07.52 # Davide-NYC: Yuck. 05.08.19 # Did you try rolling back to an ealier OF version to see if it makes a difference? 05.09.09 # urghh I may have to put the beast on eaby 05.09.12 # *ebay 05.09.31 # I don;t really have the time for this no matter how much of a masochist I really am. 05.15.17 Nick _synergis is now known as synergist (i=christop@cant.be-arsed.co.uk) 05.23.22 # jhMikeS: you around? 05.24.37 # * MarcGuay wipes a tear from his right eye 05.25.27 # good night 05.25.37 Quit Davide-NYC ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 05.28.19 Quit tvelocity (Connection timed out) 05.29.00 Join tvelocity [0] (n=tony@adsl18-66.her.forthnet.gr) 05.31.25 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 05.31.28 Quit Horscht ("http://www.geisterfahrer.org") 05.33.10 Quit MarcGuay ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") 05.33.32 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-26ba7a2ae5e39c5d) 05.46.27 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 05.51.39 Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) 05.52.26 Quit at0m ("CGI:IRC (EOF)") 05.55.47 Part steerpike 06.01.16 Join pixelma_ [0] (n=pixelma@rockbox/staff/pixelma) 06.05.20 Quit pixelma (Read error: 60 (Operation timed out)) 06.05.34 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 06.06.18 Quit jhMikeS (Read error: 54 (Connection reset by peer)) 06.06.20 Quit FlynDice ("Konversation terminated!") 06.09.23 Join Asherael [0] (n=asher@c-98-219-162-69.hsd1.pa.comcast.net) 06.10.26 Part Asherael 06.11.17 Join webguest25 [0] (n=4b3a2e07@gateway/web/cgi-irc/labb.contactor.se/x-0334f21e0a9846d5) 06.12.20 Quit Makuseru (Remote closed the connection) 06.12.20 Quit webguest25 (Client Quit) 06.12.36 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 06.13.26 Join FlynDice [0] (n=chatzill@c-24-19-225-90.hsd1.wa.comcast.net) 06.15.01 Part FlynDice 06.18.27 Quit amiconn (Nick collision from services.) 06.18.29 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 06.21.30 Join FlynDice [0] (n=jack@c-24-19-225-90.hsd1.wa.comcast.net) 06.22.28 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 06.29.48 Quit Makuseru (Remote closed the connection) 06.45.19 Join Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) 06.46.53 # oooh... charging on the e200v1 06.53.29 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 06.54.07 *** Saving seen data "./dancer.seen" 06.55.54 Quit timc`` (Read error: 110 (Connection timed out)) 06.56.24 Join timc`` [0] (n=aoeu@124.93.243.83) 07.09.12 Quit Slack_ (Connection timed out) 07.11.23 Join emancipate [0] (n=sukisuki@32.178.29.41) 07.12.31 Part emancipate 07.12.36 Part toffe82 07.13.15 Join Bagderr [241] (n=daniel@rockbox/developer/bagder) 07.13.42 Nick Bagderr is now known as B4gder (n=daniel@rockbox/developer/bagder) 07.25.47 Join Willwolfe [0] (n=chatzill@net35-14.netkaster.ca) 07.30.20 Quit Willwolfe (Client Quit) 07.40.11 # does anyone know if hwcodec has this wierd 2s transition time between the codec finishing a track and the track actually finishing like swcodec has? 07.41.04 # s/wierd/annoying 07.41.44 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 07.43.15 Quit pondlife (Read error: 104 (Connection reset by peer)) 07.47.21 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 07.47.33 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 07.48.35 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 07.55.44 Quit bmbl ("Woah!") 07.58.59 # uh oh 07.59.16 # I updated fuze 8gb with rockbox bootloader, now OF won't go into USB storage mode 07.59.21 # it might be a linux kernel bug here 07.59.25 # JdGordon: Yes, mpeg.c does call lcd_getstringsize() to make sure that the necessary glyphs for the files just buffered are added to the font cache. 07.59.27 # I am just panicking 07.59.47 # It's not odd at all to do it there - at the time of buffering, the disk is spinning anyway 08.00.02 # amiconn: yeah, ok.. just feels odd.. but I get it 08.00.23 # Swcodec buffering does the same, or at least did at the time markun committed unicode support 08.00.34 # If it no longer does, it should be readded 08.01.01 # I cant say I've looked for it in swcoded.. just noticed it in hwcodec and thought it was odd 08.02.46 # I think I want to move the elapsed time out of the mp3entry struct... It not used much outside of the wps and imo its causing problems there 08.03.12 # Hwcodec doesn't have this annoying 2..3 seconds track change offset. It has its own buffering, and then there is no codec running in advance 08.04.02 Join sajmon [0] (n=ch4os@gen2.org) 08.04.37 # Actually there is a slight offset which is bitrate dependent, due to the internal buffer of the MAS. This offset is so short with normal music that you don't notice it 08.05.13 Quit sajmon (Client Quit) 08.05.15 # The problem I've hit is with playback having to do special handling with the id3's in the last 2 sec of the track.. I dont see why things wanting the elapsed time dont call playback_elapsed() or something instead of gettingt he current tracks id3 first and using that 08.05.19 # If someone uses 8kbps mp3 files (and we had such reports in the past), it increases to about 1 second 08.06.44 Join ch4os_ [0] (n=ch4os@gentoo/user/ch4os) 08.08.02 Quit ch4os_ (Client Quit) 08.11.58 # a similar thing to this is done so scrobbler works, but I think that could be changed to be done more correctly.. how often should the wps/ui be told the current position changed? every time the codec changes is now? or X Hz? 08.13.10 Nick Anges1 is now known as Anges (n=agnes@lns-bzn-49f-62-147-173-3.adsl.proxad.net) 08.25.46 Join Rob2223 [0] (n=Miranda@p4FDCFD51.dip.t-dialin.net) 08.29.49 Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) 08.32.37 Quit kadoban (Read error: 104 (Connection reset by peer)) 08.32.37 Quit Rob2222 (Read error: 60 (Operation timed out)) 08.32.37 Quit BigBambi (Read error: 113 (No route to host)) 08.36.22 Join kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 08.37.07 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.38.47 Quit nuonguy ("This computer has gone to sleep") 08.48.38 Join igwinnimma [0] (n=chatzill@mnch-5d86b566.pool.einsundeins.de) 08.54.10 *** Saving seen data "./dancer.seen" 08.56.41 Join kadoban_ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 08.57.01 Quit kadoban_ (Client Quit) 08.57.11 Join kadoban_ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 08.57.41 Quit kadoban_ (Remote closed the connection) 08.58.02 Join kadoban_ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 08.58.31 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 08.59.09 Quit Seed (Read error: 113 (No route to host)) 08.59.09 Quit kadoban (Nick collision from services.) 08.59.17 Nick kadoban_ is now known as kadoban (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 08.59.25 Join kadoban_ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 09.05.14 Quit Makuseru (Read error: 104 (Connection reset by peer)) 09.12.43 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 09.17.52 Join petur [50] (n=petur@rockbox/developer/petur) 09.34.20 Quit qwm (Read error: 110 (Connection timed out)) 09.39.33 Join lee321987 [0] (n=chatzill@node222.36.251.72.1dial.com) 09.41.17 # does the midi player work with other patchsets now? 09.45.13 Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) 09.45.59 # I saw a question about this (alternate patchsets) in the forum that is over six months old. Is it ok to bump that thread or should I start a new one with this question? 09.46.37 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 09.48.07 Quit kadoban (Remote closed the connection) 09.50.19 # can anyone see this? 09.50.50 # yes 09.53.14 Quit lee321987 ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 09.54.03 Join axionix [0] (n=axion@cpe-67-242-94-6.nycap.res.rr.com) 09.54.05 Quit axionix (Client Quit) 09.54.39 Join axionix [0] (n=axion@cpe-67-242-94-6.nycap.res.rr.com) 09.56.49 Join kugel [0] (n=chatzill@unaffiliated/kugel) 09.58.31 Join moos [0] (i=Mustapha@81-66-158-133.rev.numericable.fr) 10.11.49 # this 2 sec transition gap is killing me :< 10.15.12 Quit Mordechai (Read error: 110 (Connection timed out)) 10.16.31 Join fyrestorm [0] (n=fyre@cpe-68-173-235-77.nyc.res.rr.com) 10.18.12 Join lasser [0] (n=chatzill@W8832.w.pppool.de) 10.22.26 # WOOO!!! I got it :D 10.22.49 Quit Genbu ("Leaving") 10.26.28 # does the nsf codec not have an elapsed time? 10.29.43 Quit Thundercloud (Remote closed the connection) 10.37.25 # isn't NSF also a non-streaming format? That's a bit problematic, e.g. the MOD codec shows something instead of elapsed time but it's the current pattern it is in, not time 10.38.54 Quit igwinnimma ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 10.39.26 Join kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 10.39.57 # I'm not sure... it just sets a number which threw me off... should be ok now 10.41.02 # I'm starting to think it might just be simpler if playback sends an event when the current track finished buffering but before the next track starts actually playing 10.45.46 # Am I wrong in thinking the id3 struct returned by audio_crrent_track() should be valid for the entire time the current track is playing? so its only ever called once per track? 10.48.23 Join sohum [0] (n=sohum@114.73.183.10) 10.48.55 Part sohum 10.54.14 *** Saving seen data "./dancer.seen" 10.57.30 Quit BHSPitLappy (Read error: 110 (Connection timed out)) 11.01.36 # JdGordon: that would be my assumption too 11.02.13 # JdGordon: shouldn't you rather send an event from pcm when the track finished playing? 11.03.39 # pcm knows track boundaries, but in a convoluted way (different callbacks). I would like to change that to a more straight-forward flag solution instead. 11.08.14 # is it really correct that set_cpu_frequency() in system-iriver.c calls timers_adjust_prescale(CPUFREQ_DEFAULT_MULT, false); for all speeds? shouldn't it use different multiplier for each speed? 11.14.49 # Zagor: yeah, thats what I'm trying to do.. without much luck 11.14.49 # So no one else with an opinion on the version string? 11.15.13 # mutt 11.15.19 # uh, wrong window 11.15.50 # /home/bjst/Mail does not exist. Create it? ([yes]/no): 11.15.54 # * B4gder shows zagor #mentionrandomopensourceapps 11.15.58 # :-P 11.16.42 # ajb: since I don't use git I don't really have an opinion 11.17.00 # * B4gder can't even spell gti 11.17.13 # I thought I had things working, but playback is too eager to overwrite the prvious tracks id3 data... I'm thinking of have 2 mp3entry structs which get used round-robbin in playback, this way the struct will be valid for the whole track, but is difficult to get working 11.19.17 # JdGordon: that sounds like a workaround rather than a fix? 11.19.57 # well, playback needs to be able to work with 2 seperate tracks at the same time.. only for a very short time, but its needed 11.20.55 # isn't it a rather long time if crossfade is active? 11.21.14 # probably.. comepletly forgot about crossfade 11.22.37 # the problem is where something calls audio_current_track() at the start of a track and not again untill the next track... once the transitioning starts playback starts overwriting that struct.. If its called during the transition it works befcause there is special handling which imo is a problem 11.24.18 # but do we really need to serve two different id3 structs? shouldn't we rather be more accurate about when the track change, and hence struct replacement, occurs? 11.24.28 # what I meant before was that playback has id3[2]... the first track would use id3[0] and the next would use id3[1], the next uses id3[2], etc.. this would need to be kept simple and just use pointers to keep track fo which to use 11.25.13 # Zagor: sure... the patch only affects git/git-svn users. I'd like to get it in because the current code freezes on pure git repos 11.25.48 Quit __lifeless (Remote closed the connection) 11.26.04 Join __lifeless [0] (n=lifeless@94.50.189.86) 11.26.35 # the other option is having playback give the codec (and itself) a temp id3 struct to use in the transition, as soon as the track really fiishes it does a memmove to the usual struct 11.26.45 # which i guess is the same thing, but less complicated? 11.27.16 # but that does give problems making sure the 2/3 threads are kept in sync 11.27.31 Join Slack_ [0] (n=brett@12-218-60-196.client.mchsi.com) 11.28.10 # the question, which part knows best about when the current track is over (no parts of it in the pcm buffer left) and the next track started? 11.28.15 Join gregzx [0] (n=chatzill@dsk189.neoplus.adsl.tpnet.pl) 11.30.13 # playback or pcmbuf... ideally pcmbuf should be kept away from everything but playback 11.30.22 # kugel: I did not tell you yet, the patch I made for 8gb fuze with additional delay's only works "sometimes" and not every time 11.30.53 # kugel: there is some problem where adding delays works, it avoids one panic, but then occasionally there is a different error 11.31.15 # On a different subject. Is the only worry about http://www.rockbox.org/tracker/task/9677 the function naming? Are people happy with the approach on the menu? 11.31.56 Join gregzx_ [0] (n=chatzill@dso217.neoplus.adsl.tpnet.pl) 11.32.13 Quit gregzx (Nick collision from services.) 11.32.25 Nick gregzx_ is now known as gregzx (n=chatzill@dso217.neoplus.adsl.tpnet.pl) 11.33.47 # kugel: pcmbuf knows that best, since it gets a callback when the dma is done. it then tells playback. 11.35.07 # another issue is its possible these can return pointers into the MoB which can move around... 11.38.11 Join BigBambi [0] (i=86ceaf40@rockbox/staff/BigBambi) 11.40.07 # "*PANIC* wait for state TRAN failed" on 8gb fuze 11.40.08 # hm 11.40.48 # kugel: I know you are working on other code right now, but do you remember seeing errors on your 4gb fuze about "wait for state TRAN failed" at all? 11.41.05 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 11.45.35 # kugel: I'm able to work-around this by sticking an mci_delay into sd_wait_for_state() but the delay is noticable now 11.46.09 Quit kugel (Read error: 110 (Connection timed out)) 11.48.02 # oh well :P 11.49.09 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 11.54.05 # this might actually work! 11.59.00 # so close! 12.00.58 # just need to fix the last track stopping early 12.01.22 # what are y'all working on anyways 12.01.25 # * lucent :) 12.01.39 # amiconn: you said you needed something to control when the storage thread did something (for sleep mode?) I think I need that for the USB stack and well, it's better if it has more other uses too. 12.04.20 Join gregzx_ [0] (n=chatzill@dso217.neoplus.adsl.tpnet.pl) 12.04.38 Quit gregzx (Nick collision from services.) 12.04.51 Nick gregzx_ is now known as gregzx (n=chatzill@dso217.neoplus.adsl.tpnet.pl) 12.06.36 Join robin0800 [0] (n=quassel@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 12.07.10 Quit robin0800 (Client Quit) 12.07.57 # amiconn: I also read you didn't experience any problem this time with USB charging the beast. Also, voltage is really a lousy way to estimate battery fullness for LiIon charging since it spends so much time in voltage regulation. 12.11.29 # can we do it any other way? 12.12.35 # I think if you have a current sense, otherwise I can't see it being too accurate. 12.16.05 # maybe we should just display a charging animation instead 12.16.33 # Unhelpful: I'm going to regression test the MAX_WIDTH workaround for fuze now 12.16.48 # it could be a few days and then I will have some results 12.17.03 # Nico_P: hey, feel like getting back into some playback hacking? :D 12.17.24 # JdGordon: maybe a little :) 12.17.43 # I saw your cue patch, but only took a quick look at it 12.17.44 # care to have a quick look at 9789? 12.17.51 # thats the one 12.18.13 # I'm reworking playback.c abit now and getting stuck, if you have a few min... 12.18.21 # sure 12.18.59 Quit markun (Remote closed the connection) 12.19.25 Join havien [0] (n=none@68-189-143-101.dhcp.wlwl.wa.charter.com) 12.19.51 Quit kadoban_ (Remote closed the connection) 12.22.00 Join kugel [0] (n=chatzill@unaffiliated/kugel) 12.22.21 Join PaulJam [0] (i=PaulJam_@vpn-3064.gwdg.de) 12.23.01 Join robin0800 [0] (n=quassel@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 12.23.06 # kugel: updated long delay patch http://nopaste.com/p/a4iSpWo4cb 12.23.18 # seems to work a lot better than the earlier one I told you about 12.23.23 Join DerDome [0] (n=DerDome@dslb-082-083-223-248.pools.arcor-ip.net) 12.24.35 # the wheel still triggers a button press unless I apply the MAX_WIDTH 8 patch for graphics though 12.24.59 # don't know how or why if those are related in hardware 12.25.52 # Nico_P: http://pastebin.com/d6b11b2fc is what im working on now... trying to get playback to use 2 seperate id3 structs, and it seems to work except the last ~2s of the last track of the playlist doesnt play (or if it does, the wps doesnt show any updates.....) hopefully you have an idea what might be wrong 12.32.07 Quit gevaerts (Nick collision from services.) 12.32.07 # I can't really remember what exactly happens at the end of the playlist, but I guess the codec has stopped and the PCM buffer is emptying 12.32.16 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 12.32.41 # yeah, as far as i can tell its cutting off early waiting for pcm to finish in the codec thread 12.33.09 # maybe because the elapsed time isn't quite right 12.33.54 # thistrack_id3 gets zero'd before that point :/ 12.34.01 # Zagor: I was thinking the same thing really. 12.34.29 # JdGordon: it shouldn't, but I guess you know that :) 12.35.51 # audio_load_track() looks like its memsetting the wrong one 12.35.57 # callback overload :-( 12.37.18 # JdGordon: what are the benefits you are aiming at with this change? 12.38.01 # read my rambling about 70min ago... but bassically, clean things up between the wps and playback 12.38.26 # * Nico_P goes to read 12.39.01 # I think we should remove much of the abstractions from playback. there's way too much hot-potatoing going on. 12.39.47 # what do you mean by "hot-potatoing"? 12.40.18 # functions that merely pass data forward to another function/queue/thread 12.41.23 # however I'm chiefly annoyed by all the callbacks. they make the code _very_ hard to follow. 12.42.12 # lucent: "the wheel still triggers a button press unless I apply the MAX_WIDTH 8 patch for graphics though" that is actually too weird for my mind 12.45.13 # pcmbuf_callback_queue_post() is a typical hot potato function. why is it there? it's even used in only one place. 12.46.21 # * JdGordon seems to have chosen the wrong place to do the pointer swapping 12.49.44 # Zagor: Because normal kernel interrupt masking doesn't mask audio interrupts and some special handling is needed or corruption is possible. 12.50.06 # but no handling is done? 12.50.22 # no handling? 12.50.39 # it just calls queue_post(). nothing else. 12.50.58 # * jhMikeS wonders if someone changed something 12.51.24 # /* No lock since we're already in audio interrupt context */ 12.51.32 # ah, no it's right 12.52.26 # on the tail end it synchonizes there. no thread ever waits on the queue so it's safe. 12.52.46 # s/tail/head 12.53.44 Join markun [50] (n=markun@rockbox/developer/markun) 12.54.19 *** Saving seen data "./dancer.seen" 12.55.55 # oh. I see the codec triggers Q_AUDIO_TRACK_CHANGED. that can't be right. 12.56.01 # ... it seems there is a difference between resuming a playlist and starting a new one, regardless of the buffer state :/ 12.56.11 Join webguest92 [0] (n=4e93a58a@gateway/web/cgi-irc/labb.contactor.se/x-b8da279210fe0138) 12.56.21 # resuming doesnt get the id3entry properly but it gets it from the MoB which is no good 12.56.35 # JdGordon: ouch 12.57.04 # codec_pcmbuf_track_changed_callback also does from pcm interrupt context 12.57.06 Quit webguest92 (Client Quit) 12.57.41 # Nico_P: do you tihnk moving the cue handling closer into playback is a good idea? 12.57.46 # oh it does? why is it called codec_ then? 12.58.07 # heck if I know. 12.58.10 # :-) 12.58.35 # JdGordon: yes. I've been wanting to do it for some time 12.58.47 # Line 1152: pcmbuf_set_event_handler(codec_pcmbuf_track_changed_callback); 12.59.28 # and greping for it is useless, since that doesn't show where it is called from :-( 13.00.16 # You're getting into the dark bowels of playback where things are very twisted (codec_track_skip_done btw) 13.00.46 Quit kugel (Remote closed the connection) 13.01.01 # yes. I'd like to take my big mop to it. 13.01.24 # are events as bad/hard to follow as callbacks? 13.02.07 # It's bad in that a particular operation seem to happen in multiple ways 13.02.20 # the best in my opinion is simple flags that dictate which code path is used. 13.02.36 # Like how to know where to find were the pcm buffer should be flushed or something along that line 13.02.46 # jhMikeS: and you don't know how many different ways there might be 13.03.22 # I lost count (sort of an exasperated joke, sort of) 13.05.29 # I just remember trying to deal with placing the right pcm control in the right spots and it just proved difficult to determine how it would arrive at a certain places under different conditions. 13.06.27 # indeed 13.09.41 # ohmigod! it's mixing the events in audio_queue and pcmbuf_queue. and both get Q_AUDIO_TRACK_CHANGED posted to it 13.10.15 # lalalalala 13.11.05 # haha. well, it picks one or the other queue to pull the event from. 13.11.31 # yeah. why then have two queues? 13.11.41 Join midkay [0] (n=midkay@rockbox/developer/midkay) 13.12.30 # because we can't let FIQ or DMA level interrupts interact with threads 13.13.11 # It just doesn't deal with it in the kernel and may corrupt things. 13.13.35 # ah 13.14.01 # I have been thinking about a nice way to allow it to deal with it though. I want it simple though. 13.14.27 # alrighty! I tihnk we are ready for mass testing... who's game? :D 13.14.37 # need some hwcodec testing also as i dont have one 13.15.16 Quit robin0800 (Remote closed the connection) 13.15.48 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 13.19.05 # bah, crossfade doesnt work 13.19.29 # Really, I think you could use a counter for the number of track changes "posted" and do time progression using pcm samples played like mpegplayer (the timestamping isn't needed) 13.19.44 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 13.22.43 Join kugel [0] (n=chatzill@unaffiliated/kugel) 13.25.44 # well.. crossfade bloody breaks everything! 13.26.40 # how does the elapsed time get reported once the fade start? it looks like the regular codec callback, but I expected the pcm callback? 13.28.27 # heh...crossfade 13.29.09 Join AndyIL [0] (i=AndyI@212.14.205.32) 13.29.24 # actually.. this looks like the track change event gets fired too early 13.29.31 # JdGordon: I'm guessing that it progresses for the previous track until it plays out the it starts on the faded-in track 13.31.04 # * jhMikeS suggests modeling a crossfade and all parameters on paper in a graph and precisely defining each part and where one track ends and the other begins. 13.34.50 # when should the track changeover be? at the usual end of the first track? 13.35.01 # there was thoughts about disabling crossfade temporarily, wasn't there? 13.36.19 # kugel: I had far worse thoughts about it :) 13.36.30 # JdGordon: yes, the track change point doesn't change with crossfade 13.40.11 Quit AndyI (Read error: 110 (Connection timed out)) 13.45.20 Quit robin0800 ("Leaving") 13.45.40 Quit fyrestorm ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 13.45.47 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 13.49.09 # oh nice! it seems crossfade isnt actually being displayed correctly in svn either 13.49.49 # yea, nice :) 13.50.28 # well not really.. but it means i can send this off to the tracker knowing its no worse than svn :p 13.56.32 # guys (and pixelma :D ) please test 9795 14.05.22 # cool! I somehow segfaulted running 2 different copies of the sim at the same time! both e200-sim but in complely seperate directories 14.06.06 # and now i've got broken tags on at least one track 14.06.19 Join Schmogel [0] (n=Miranda@essn-4db64dca.pool.einsundeins.de) 14.10.57 Join tyfoo [0] (n=tyfoo@dyndsl-095-033-121-096.ewe-ip-backbone.de) 14.11.18 Join TheSphinX^ [0] (n=cold@p54A5BF82.dip.t-dialin.net) 14.11.32 # JdGordon: I'll test on e200 and clip 14.11.42 # both target, that is 14.11.46 # thanks 14.12.07 # i think playlist resume might be broken... but please dont let that stop you :) 14.12.22 # actually, playlist position saving is broken, resume should work 14.15.03 # maybe not... might just be the sim 14.15.15 # well, that doesn't work for the clip in svn anyway :) 14.15.37 # (at least not on mine) 14.16.10 # No, I'm just an idiot... resume works fine... im too tired 14.19.01 # I just meant, that saving playlist position is broken, as well creating any other file 14.30.10 Part B4gder 14.43.20 Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-3cb162a5a0c7930b) 14.43.48 Join nplus [0] (n=nplus@243.131.Globcom.Net) 14.45.24 # well i've just about got through a whole cd without any crashing or fubar id3.. and scrobler seems to still be working... 14.45.42 # JdGordon: seems to work 14.45.55 # did the first trak have fubar id3? 14.46.22 # ne 14.46.25 # no 14.46.32 # track change transition seems perfectly in time 14.46.57 # on your target that can resume playlists... can you stop then resume? does it show the correct info? 14.47.10 # there's a little glitch though, 2s before the track ends, the UI seems to lag shortly, such that scrolling acts weird for a short period 14.47.20 # yep 14.47.28 # I stop->resume works 14.47.31 # -I 14.47.32 # good 14.47.37 # also, play->reboot->resume works 14.47.39 # which target was that glitch with? 14.48.02 # e200 14.48.13 # every track? 14.48.51 # yep 14.49.05 Join Jaykay [0] (n=chatzill@p579E66AC.dip.t-dialin.net) 14.49.39 # wierd... its too early for the wps to be doing its full redraw, not sure 14.49.47 # putting it on my h300 to see if it happens 14.50.46 # well, the track info changes in time, it's just a "interruption of the UI" 14.51.00 # maybe just a stop_scroll call a bit too early 14.53.13 # how do i copy text in the vmware player? or at least store it in a file? 14.53.29 # JdGordon: another ui glitch: if I keep changing the volume, next track info doesn't update until I stop changing the volume 14.53.50 Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-7453fc04ee3233a5) 14.53.56 # from the 2s-before-track-end to release-volume-up-button 14.54.12 # kugel: other problem first... lag? or does it seem to jump to the next track too early? 14.54.19 # kugel: does it compile for you for e200? 14.54.22 *** Saving seen data "./dancer.seen" 14.54.26 # im seeing the 2nd on my h300 which i wasnt seeing on the sim 14.55.27 # JdGordon: lag, most certainly. let me describe it: I ffw to near the track end (e.g. 10s before), then I watch at the track and next track info 14.55.39 # This is strange... I rolled a Clip build from a clean SVN trunk, and my Clip still freezes when trying to start up. 14.55.49 # JdGordon: could your patch influence the availability of the next-track info? it seems to be missing for tracks that are not yet buffered. 14.55.58 # 2s before the end, every info that scrolled, stopped scrolling, started again, stops again (all within 0.5s), and then works normally for the rest 1.5s 14.56.17 # PaulJam: I've not noticed that 14.56.21 # * LambdaCalculus37 catches kugel's attention 14.56.25 # and I tried that 14.56.30 # what the ...? I get "bad checksum" from the bootloader on my clip build. 14.56.48 # LambdaCalculus37: yea, delete the config.cfg. the clip apparently creates corrupt files 14.57.17 # kugel: Will do. 14.57.23 # I'm having this problem too. Only on the clip though, not on my fuze 14.57.28 # PaulJam: its possible.. I might need to work something out so the wps is told when that info is available 14.57.41 # kugel: I kept wondering what the hell was causing it. 14.58.04 # * LambdaCalculus37 deletes his config.cfg from the Clip 14.58.08 # JdGordon: I tested this case, and it seemed to work. I skipped the tracks in view buffering until it was nearly empty, then I went to the wps and it showed next track info fine 14.58.19 Part LinusN 14.58.57 # kugel: Still not booting. 14.59.15 # I might be a bit overzealous with how often im letting the wps redraw 14.59.44 # The firmware length is 69F18, and the checksum is 2AFB0B8. 15.00.04 # LambdaCalculus37: try updating the bootloader, maybe that helps 15.00.58 # kugel: I'll see if I can get mkamsboot to build under OS X. 15.01.42 # grr.. i had crossfade on accidently... 15.01.50 # kugel: i still dont see the lag you're talking about 15.02.02 # PaulJam: I tihnk you're right.. that needs fixing.. 15.02.56 # JdGordon: have you some scrolling lines? it's most noticeable as scrolling stops 15.03.09 # yes 15.03.21 # JdGordon: and again, PaulJam's issue worked fine here 15.03.57 Quit dfkt (Read error: 110 (Connection timed out)) 15.04.15 # kugel: could you try with large files (bigger than the buffer)? there it should happen already on the first track. 15.04.49 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 15.05.12 # (i see this on a H300, maybe this is a timing issue. Hardisk vs flash) 15.05.58 # my h300 is CF, seems skipping prev trck a bit is a easy way to get this 15.06.02 # maybe 15.06.53 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 15.08.12 # kugel: I'm having a little trouble getting mkamsboot to build on OS X, and I can't sit to fix it right now. 15.08.55 # really? 15.09.13 # just make doesn't work? afaik it doesn't contain any OS specific code 15.09.38 # kugel: I may have to look into it later, but I can't right now (work). 15.09.47 # PaulJam: right, it's a bit messed up with files larger than the buffer 15.09.57 # LambdaCalculus37: I'll upload it, wait a second 15.11.10 # kugel: My OF is the latest version (1.1.30). 15.11.26 # PaulJam, JdGordon: is the issue with next track info that it is not available at all when skipping further than what is already buffered or it just takes a little longer to appear? 15.12.12 # I think its taking alot longer to appear because of my changes 15.12.35 # LambdaCalculus37: http://www.alice-dsl.net/simonemartitz/rockbox/mkamsboot 15.12.46 # the latter already happens in SVN (haven't tried the patch myself yet, maybe one of you should compare) 15.13.27 # JdGordon: it also shows wrong information here (2 files in the playlist, each bigger than the buffer) 15.13.49 # pixelma: for me the info does not appear for the entire duration of the track. 15.14.10 # kugel: Is this mkamsboot for OS X, or for Linux? 15.14.44 # for linux, I guess it doesn't work? 15.15.06 # LambdaCalculus37: if you donate a mac, I'll fix it :D 15.15.30 Quit Seed ("cu, Andre") 15.15.35 # kugel: The only other Mac I have runs OS 9.2.2. Not unless you want to write RBUtil for OS 9. ;) 15.16.00 # kugel: you want a mac ssh account? 15.16.24 # hm, wouldn't be a bad thing I guess 15.16.31 # * kugel gotta run, see you 15.17.06 Quit kugel (Remote closed the connection) 15.17.54 # PaulJam: Ifixed 15.18.07 # JdGordon: Since you're the only other dev I know with a Mac, have you been able to build mkamsboot in OS X? 15.18.22 # I havnt tried 15.18.30 # preglow: has a mac also iirc 15.19.16 # svn up-=ing on my mac to try 15.19.27 # Okay. 15.20.08 # Zagor: cpu_set_frequency() calls timers_adjust_prescale() twice. Once when switching to bypass, one after the pll locked to the new freq 15.20.09 Quit lasser ("ChatZilla 0.9.84 [Iceweasel 3.0.5/2008122011]") 15.20.11 Quit Jaykay (Read error: 110 (Connection timed out)) 15.20.30 # This is necessary to keep precision as accurate as possible 15.20.31 # amiconn: yup, I saw that later 15.20.49 # LambdaCalculus37: forgot.. i dont have the CC's installed and havnt been able to get them going either, so cant try 15.20.52 # JdGordon: have you posted the new patch somewhere? 15.21.16 # not yet... 15.22.06 # JdGordon: I'll try again on my Mac later on. 15.22.44 # preglow: (for the logs) When you can, see if mkamsboot builds in OS X. 15.23.56 # * LambdaCalculus37 thinks that most of the tools should be looked through to make sure they also build on OS X 15.24.16 # I'll make a note of that for Mr. Someone. ;) 15.25.40 # PaulJam: ok, its on the tracker... 15.25.45 # * JdGordon -> bed 15.25.47 # ok 15.25.49 Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) 15.26.19 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 15.30.28 Join troy_ [0] (n=toppy@78.146.244.178) 15.32.59 Join Jaykay [0] (n=chatzill@p579E66AC.dip.t-dialin.net) 15.36.11 Quit robin0800 (Remote closed the connection) 15.36.31 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 15.37.23 # JdGordon|zzz: i get some errors while compiling rockbox for e200 with your patch... should i write the errors here/somewhere else? 15.41.41 # Jaykay: add a comment to the patch in flyspray 15.44.07 # ok... how can i save the text of the error (maybe in a txt file, im using vmware player) 15.44.33 # I don't know vmware, I'm afraid 15.46.28 # Jaykay: copy/paste works accross host/vm in vmware 15.47.05 # unfortunately not. 15.47.27 # Jaykay: if you have internet access from within the vm, you can upload it somewhere 15.48.52 # mcuelenaere: i think the image from the wiki doesnt have a browser... and even if i think strg-c is not working in the console 15.49.03 # strg is not working 15.49.08 # *strg v 15.49.48 # you're doing make right? try doing make > output.txt &2>1 15.51.05 # make > output.txt 2>&1 15.51.43 # it says [1] 31801 and creates a empty output.txt 15.51.51 Join BdN3504 [0] (n=55b23f5b@gateway/web/cgi-irc/labb.contactor.se/x-8280b3db247cd072) 15.52.02 # you mean when doing the first or the second command? (the first was wrong) 15.52.10 # gah, /me committed too much :-( 15.52.20 # and [1] 31801 means it started a job with PID 31801 15.52.35 # type 'jobs' to see whether it finished 15.52.42 # then do 'cat output.txt' 15.53.22 # hey, i read about http://svn.rockbox.org/viewvc.cgi?view=rev;revision=19754 does that mean i can change the target status under the column USB on the wiki http://www.rockbox.org/twiki/bin/view/Main/TargetStatus#New_Platforms_Currently_Under_De to "Yes"? 15.53.47 # mcuelenaere: the second command worked, thanks! 15.54.14 Quit Failrar ("Leaving") 15.54.20 # BdN3504: yes, that should be changed now I gues 15.54.21 # guess* 15.55.00 Join {phoenix} [0] (n=dirk@p54B47538.dip.t-dialin.net) 15.59.28 Quit BdN3504 ("CGI:IRC (EOF)") 16.00.31 Join fyrestorm [0] (n=fyre@cpe-68-173-235-77.nyc.res.rr.com) 16.04.03 Quit CaptainKewl (Read error: 110 (Connection timed out)) 16.06.58 Join tyfoo2 [0] (n=tyfoo@dyndsl-095-033-037-154.ewe-ip-backbone.de) 16.21.23 Quit tyfoo (Success) 16.21.24 Nick tyfoo2 is now known as tyfoo (n=tyfoo@dyndsl-095-033-037-154.ewe-ip-backbone.de) 16.24.58 # hmm, boost seems to not work on clip 16.30.44 # I made a small test_boost plugin that simply updates a counter and displays it on the screen. then I trigger boost on/off with up/down. but I can't see any difference between off and on. 16.36.14 # gevaerts: is usb_drv_recv() supposed to be blocking? 16.36.21 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-02376e4087e10210) 16.37.01 # Zagor: I was curious about clocking on the clip, so i made a plugin that calculates the clock rate on ARMv4 by doing SMLALs and timing how long it takes 16.37.07 # i forgot to try it on the clip though 16.37.16 # want me to look at it later? 16.37.23 # please do 16.39.41 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 16.44.10 Quit mcuelenaere (Read error: 113 (No route to host)) 16.44.12 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 16.47.17 Quit axionix (Read error: 60 (Operation timed out)) 16.47.21 Join grndslm [0] (n=grndslm@24-119-80-142.cpe.cableone.net) 16.51.14 Quit Horscht ("Snak 5.3.3 Unregistered copy. Evaluation period is over. Program will now quit. Thanks for using Snak.") 16.52.36 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 16.54.24 *** Saving seen data "./dancer.seen" 16.55.40 # mcuelenaere: no 17.00.09 Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-d1bb7d7eebdc9a18) 17.03.03 Quit Zagor ("Client exiting") 17.05.22 Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) 17.17.31 Join sadur [0] (n=5810d95c@gateway/web/cgi-irc/labb.contactor.se/x-b1f795f4b23dcce3) 17.18.14 Quit sadur (Client Quit) 17.31.27 Quit jhulst (Remote closed the connection) 17.34.17 Quit Xerion (Read error: 104 (Connection reset by peer)) 17.35.14 Quit einhirn (Read error: 104 (Connection reset by peer)) 17.35.34 Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) 17.39.03 Quit markun (Remote closed the connection) 17.39.04 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 17.43.41 Join Xerion [0] (n=xerion@82-170-197-160.ip.telfort.nl) 17.44.12 Join flydutch [0] (n=flydutch@host159-157-dynamic.1-79-r.retail.telecomitalia.it) 17.51.37 # little question, shouldn't a disk spinup automatically cause rebuffering when the buffer is below a certain threshold? 17.52.00 Join markun [50] (n=markun@rockbox/developer/markun) 17.52.32 Join kugel [0] (n=chatzill@unaffiliated/kugel) 17.55.36 Join facta [0] (i=facta@gateway/tor/x-27abf71593ad6ccc) 17.56.07 Nick Barahir_ is now known as Barahir (n=jonathan@Ya01a.y.pppool.de) 17.57.47 # PaulJam: Do you mean "is it already supposed to" or "wouldn't it make sense to" by "shouldn't it"? 17.58.52 # i thought it is already supposed to. If i remember correctly this was added a long time age (more than 1 year ago). 17.59.41 # If it was there ought to be an associated SVN revision. You could check and see if maybe it was and then removed, or simply was never added just discussed? 18.03.10 # IIRC that feature was made in the early ages of swcodec playback (by Slasheri), and was removed by loslogic? 18.03.36 # seems like it was added in r11451, but i have no idea when or why it was removed. 18.04.22 # search for lostlogic's rework, and you will find 18.05.08 # for the reason, best to ask loslogic, I believe that it was remove for make the playback "beast" a bit friendly 18.06.18 Quit {phoenix} (Remote closed the connection) 18.07.13 # well, if it was removed intentionally i'm ok with it. 18.07.55 # LambdaCalculus37: i has a mac 18.07.56 Quit petur ("work->home") 18.08.04 # hmm 18.08.11 # i can try 18.09.22 # I'm sure it was :) , lostlogic was one of the very few that had the courage to try to understand the playback code, and tried to improve it. 18.09.34 # preglow: Not just mkamsboot, but mknkboot and tcctool should probably be looked at, too. 18.10.54 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 18.12.02 # mkamsboot requires a cross compiler, so i can't tes that 18.12.18 # i haven't been able to make native os x crosscompilers work 18.14.11 Join karashata [0] (n=karashat@69.41.192.215) 18.15.27 # LambdaCalculus37: so, I could build a svn bootloader for you if mkamsboot doesn't work 18.15.45 # ok, i just created dummies of all i couldn't cross compile, mkamsboot itself compiled 18.15.50 # but the binary will of course not work 18.15.57 # kugel: I have 01.01.30 as my OF. 18.16.09 # got 1 warning 18.16.20 # preglow: I haven't had much luck with the native OS X crosscompilers, either. 18.16.39 # i did manage to compile the very newest gcc for arm 18.16.46 # but only god knows where i put it 18.16.50 # preglow: What about tcctool and mknkboot? 18.16.55 # i remember i made a build that worked with it too, some codecs had troubles tho 18.17.04 # Those three are the more critical tools. 18.18.13 # mknkboot compiles just fine 18.18.17 # tcctool needs libusb, give me a sec 18.20.32 # preglow: I think libusb is available via Fink; if not, MacPorts should have it. 18.21.09 Join m0f0x [0] (n=m0f0x@189-47-76-33.dsl.telesp.net.br) 18.21.33 # i've installed it via macports 18.21.35 Quit BigBambi ("http://www.mibbit.com ajax IRC Client") 18.21.42 # and works fine after, once i fixed the makefile to use LDFLAGS 18.21.49 # is there any env variable gcc automatically checks for libraries? 18.22.32 # * LambdaCalculus37 isn't sure 18.22.55 # i really would think so 18.23.05 # preglow: Should the fix for the makefile go into SVN or no? 18.23.16 # but i see macports has only fixed LDFLAGS to point to /opt/local/lib, and that needs to be actually used on the command line to be included 18.23.24 # LambdaCalculus37: it should go into svn if there is no better solution 18.23.42 # i find it highly unlikely that there is no gcc-check-this-directoryu-for-libs variable 18.24.15 # LambdaCalculus37: http://www.alice-dsl.net/simonemartitz/rockbox/m300t.bin 18.24.48 # kugel: Thanks. 18.25.13 # preglow: /usr/include on linux, probably something similar on mac 18.25.16 Quit gregzx (Connection timed out) 18.25.47 # kugel: that's for include files, not libs, and i'm looking for an environment variable anyway 18.26.06 # oh, nevermind then 18.26.14 # google should reveal something 18.26.50 # sometimes you need to add -l as gcc parameter, might that be the reason? e.g. if you want math.h, you need to add -lm 18.27.03 # * LambdaCalculus37 still can't get his Clip to boot fully 18.27.13 # LIBRARY_PATH sounds like a good alternative 18.27.29 # LambdaCalculus37: "fully"? 18.27.30 # kugel: nah, i've got all that stuff in check, just need to make gcc search the right places 18.27.43 # ok :) 18.27.53 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.28.35 # LambdaCalculus37: maybe you try deleting the entire .rockbox folder? 18.29.04 Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) 18.29.23 # kugel: The bootloader is stopping at the Rockbox logo. The build is not starting at all. 18.29.46 # LambdaCalculus37: yeah, LIBRARY_PATH was it, hopefully standard macports install (mine was botched) uses that 18.29.50 # so keep the makefile as is 18.29.55 # Okay. 18.30.49 # jhMikeS: I don't entirely understand how r19762 changes behaviour on the usb bus 18.33.27 # LambdaCalculus37: does it say boot at the version string or not? if not, it loaded rockbox already, and rockbox fails to start 18.33.27 # gevaerts: It changes alot and prevents misbahavior when threads decide not to ack. 18.34.01 # * gevaerts reads some more 18.34.27 # gevaerts: one thing that interests me is if it is legal to mount as USB mass storage but not present any storage as an alternative for charging only. 18.34.31 # jhMikeS: if I read the code correctly, now it is possible for both the host and rockbox to access the filesystem simultaneously... 18.35.07 # nope 18.36.09 # It sets exclusive_storage_access to true on connect, before rockbox has released the filesystem 18.36.29 # kugel: It does. 18.36.39 # no more possible than before since the ata thread doesn't call idle notifys. all other threads are in wait. if no thread acks, the driver is never activated. it behaves similarly to having an ATA bridge. 18.37.20 # Why are all other threads in wait? 18.37.51 # if they ack, then they have acked that they have released the disk and are waiting for disconnect. 18.37.55 # LambdaCalculus37: hm, you should try formatting :/ I needed to several times too with my clip to make it working somehow 18.38.18 # Sure, but if they don't ack they could be anywhere 18.38.33 # kugel: No need to. :) 18.38.36 # then the driver isn't actually started 18.38.36 # * LambdaCalculus37 got it working now 18.38.52 # it does just what it should do 18.39.48 # ok. I misread something somewhere apparently 18.41.08 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 18.41.26 # kugel: I deleted the .rockbox folder and just extracted a fresh build. 18.41.31 # maybe we could suppress the "make reconf" warning during make reconf? 18.41.42 # As to your other question : it's not possible to have a mass storage device with no volumes (because the number is given back as MAX LUN, which is zero based). It would be possible to present a removable drive with nothing inserted, or a small ramdisk with a text file explaining things 18.41.47 # kugel: the bitmaps, did any break? ;) 18.42.00 # Unhelpful: ah sorry, I totally forgot 18.42.25 # that's ok. do you know what width the largest cover on your fuze is? 18.42.26 # jhMikeS: hey, can you help me quickly? 18.42.51 # Unhelpful: album art? they're all 150x150 18.42.56 # gevaerts: I did try presenting no media ready and Windows accepted it and configure it without drives (using the storage driver instead of the charging only driver). 18.43.34 # kugel: we never determined the size at which corruption starts. i think w=150 might be too small... maybe start with the test bitmap just under that, and work up from there? 18.43.58 # gevaerts: But you're saying that strangness is illegal? 18.44.02 # kugel: sure 18.44.04 # Unhelpful: I'll test all, don't worry :p 18.44.26 # jhMikeS: I don't quite understand what this commit did r19714. And it seems to cause corruption on the clip 18.44.30 # jhMikeS: I'm not sure I follow. 18.44.48 # fine, if you want... but i suspect that we may be safe up to at least 150, since you said no AA corrupted. 18.44.58 # jhMikeS: funman seemed to introduce some retry, but the only time he checks it, he sets it false before 18.45.22 # that's in this while(1) data transfer loop. I don't see retry being conditional or something 18.45.39 # also, the greyed-out icons that were corrupted in your WPS screenshot are background, not part of the bitmap strips... so, again, it's a wide bitmap that's corrupted 18.46.11 # jhMikeS: i have card readers that let you hotplug the card, rather than the reader, with varying degrees of success 18.46.20 # Unhelpful: the progressbar was a bit corrupted too 18.46.26 # one of them needs a usb replug if you've sent an eject command. 18.46.35 # kugel: that's also screen-width, or nearly so. 18.47.03 # jhMikeS: plus, maybe you can tell me, I don't quite understand what wakeup_wait does and/or if it needs any preparation 18.47.10 # gevaerts: storage non-exclusive, SENSE_NOT_READY/ASC_MEDIUM_NOT_PRESENT/send_csw(UMS_STATUS_GOOD) (just a guess setup) 18.47.58 Join saratoga2 [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-5e2570967dfc5d84) 18.48.03 # jhMikeS: UMS_STATUS_GOOD means that the unit is there and working fine, so the host will not even ask for sense data 18.48.09 # kugel: wakeup_wait block a thread until something calls wakeup_signal. If no thread was waiting, the state remains signaled. 18.48.15 # do i have to do something special to get a sansa to mount in ubuntu? mine just sits in the OF charging 18.48.22 Quit saratoga ("CGI:IRC (Ping timeout)") 18.49.00 # saratoga2: is it set to MSC? 18.49.29 # gevaerts: yes it works normally in Windows, but i'd like to sync via my linux machine 18.49.38 # kugel: The only preparation is to call wakeup_init before ever using it 18.50.17 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 18.51.14 # saratoga2, my sansas (e260, c240, clip) mount fine on ubuntu 8.10 18.51.28 # jhMikeS: _init or _signal? other code seems to do wakeup_signal 18.51.44 # switching USB ports fixed it, how odd 18.52.33 # gevaerts: I took a guess at trying to expose a USB device but no actual storage (which it seemed to strangely cooperate with pretty well). 18.52.36 # saratoga2: did switching help, or is it just random? I know that if it's set to Auto instead of MSC it sometimes works, but not always 18.52.54 # i don't have an auto option on mine, and its been working fine with windows for 2 years now 18.53.05 # jhMikeS: any idea for the retry? the commit message said "Retry blocks transfer if a problem happened ", but I can't see how it is determined whether a problem occured 18.53.51 # saratoga2: in that case it's probably just showing some sansa OF randomness... 18.53.53 # kugel: Code that wants to wakeup a thread waiting for something to finish calls _signal. init just initializes the object for use (like mutex_init, queue_init, etc.). It's like mutex_lock, semaphore_wait, or queue_wait(_w_tmo). 18.54.27 *** Saving seen data "./dancer.seen" 18.54.38 # wakeup signal is analagous to queue_post, semaphore_release, mutex_unlock, etc. 18.55.04 # jhMikeS: ok, I don't see wakeup_init in that file, it's presumably done in another file? 18.55.25 # looking at creative zvm dma, there's no wakeup_init either 18.55.33 # kugel: It should be initialized. No kernel object should ever be used without calling the _init. 18.55.59 # oh, nevermind, I found it 18.56.05 # And no kernel object should have init called more than once unless it is guaranteed to not be in use at the time. 18.56.50 # Of course we could add loads of verification code too :) 18.57.21 # gevaerts: while you're here, how do i unmount from the command line? 18.58.44 # jhMikeS: thanks 18.58.52 Join archivator [0] (i=archivat@77.70.28.57) 18.58.55 # jhMikeS: any idea on the retry? 19.00.06 # I assume it should rather be "retry = wakeup_wait()"? Otherwise I cannot imagine how retry can ever be true 19.01.16 Join Jaykay_ [0] (n=chatzill@p579E66AC.dip.t-dialin.net) 19.01.18 # in case anyone is wondering, the e200v1 boosts to 79.71MHz +/_ the accuracy of our timers 19.01.19 Join alexbobp_ [0] (n=alex@69.149.25.200) 19.01.21 # kugel: looking 19.02.02 Quit alexbobp (Nick collision from services.) 19.02.07 Nick alexbobp_ is now known as alexbobp (n=alex@69.149.25.200) 19.03.13 # kugel: I don't understand where the retry actually retries. It doesn't appear to do so. 19.03.46 # yea 19.04.50 # kugel: whats the best way to format my Fuze to 1GB without ruining the firmware partition? 19.05.06 # saratoga2: mkfs.vfat 19.05.38 # The e200 would fail to read the main device after an SD card insertion and it appeared needed to retry the first transfer after that. For the SD it just makes it not give up so easily. 19.07.03 # kugel: is it possible to brick the device using that command? 19.10.11 # saratoga2: I don't think so. I used it (and reverted) successfully multiple times 19.11.15 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) 19.12.11 # jhMikeS: I assume retry should be dependent of the return value of wakeup_wait? 19.12.27 Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) 19.12.34 # it doesn't seem to work though, I effectively disabled write support :/ 19.15.56 # kugel: no, it gets signaled. if retry is true it should try reinitializing the card and doing the transfer again. 19.16.06 Quit Jaykay (Read error: 110 (Connection timed out)) 19.16.31 # kugel: do you happen to remember the command you used? 19.17.10 # saratoga2: I think it was "mkfs.vfat -b 800000 /dev/sdX". 19.17.36 # the block number is a bit confusing, as mkfs.vfat apparently reports 1024bytes blocks 19.18.18 # jhMikeS: so how to determine a unsuccessful transfer? 19.19.09 # ah, I think I know how it's supposed to work 19.20.06 # the ISRs may set retry = true, and those seem to happen between retry = false and if (!retry) (e.g. within wakeup_wait) 19.20.33 # it looks based off ata-sd-pp.c so you can see that in original form. 19.22.12 # kugel: Yes, the interrupt will set retry to true if there is an error and wakeup the waiting thread 19.23.16 # kugel: Have you tried Vorbis playback on the Clip with Rockbox? 19.23.49 # saratoga2: "umount /dev/" 19.23.50 # kugel: any idea? http://pastebin.com/m6e56a220 19.24.27 # saratoga2: oh, apparently -b was wrong, try without 19.24.28 # retry should probably be volatile since it's modified out of the normal flow. The compiler could optimize away a reload of the value after waktup_wait (strictly speaking). 19.25.03 # good idea 19.25.19 Quit tvelocity ("Αποχώρησε") 19.25.42 # he even may cut it the whole if (!retry) away, seeing it it always gives false 19.26.56 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 19.27.07 # kugel: just out of curiosity, is the system firmware partition hidden? 19.27.22 # there's no seperate afail 19.27.23 # err hidden in UMS mode i mean 19.27.25 # afaik* 19.27.46 # it's all one, with some very weird black magic partition table (to me, and fdisk) 19.28.03 # but the usb controller hides the start of flash memory or something in UMS mode which is why it doesn't brick? 19.28.44 # yes, the of doesn't expose the firmware parts, and rockbox doesn't do that as well, currently 19.30.00 # Unhelpful: Im curious - what is r19765 good for? 19.30.54 # The greylib buffer ends up in the same part of memory one way or another, you just swapped plugin bss for the same part of memory requested via plugin api 19.30.57 # gevaerts: Windows still configures it if I return 0 luns. hehe. 19.31.37 # jhMikeS: it doesn't return 0 luns. It says the highest-numbered lun is 0 (so 1 lun) 19.32.08 # not there but in SCSI_REPORT_LUNS 19.32.30 # lun_list_length = 0 19.32.51 # oh. I'm not sure how valid that is 19.33.55 # Me neither, I'm observing what happens. I really should just read if I look into this possibility seriously. 19.36.51 # Have fun with the SCSI specs :) 19.37.26 # Any recommended docs regarding this particular aspect? 19.38.30 # http://www.t10.org/scsi-3.htm knows all. I think you mainly need the SPC and SBC specs 19.39.21 # thanks 19.39.32 # I've worked with SPC-3 and SBC-2 mostly 19.39.50 Quit archivator ("Leaving") 19.40.58 # You may also want the USB mass storage specs from http://www.usb.org/developers/devclass_docs#approved but I don't think they're very important for what you need 19.43.06 Quit Thundercloud (Remote closed the connection) 19.47.37 Join kugel_ [0] (n=chatzill@e179038065.adsl.alicedsl.de) 19.53.56 Join archivator [0] (i=archivat@77.70.28.57) 19.54.03 Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) 19.54.49 Quit dfkt (Nick collision from services.) 19.54.53 Nick dfkt_dt is now known as dfkt (i=dfkt@unaffiliated/dfkt) 19.55.45 # Just my luck. I completed my no-lcd_update-when-backlight's-off benchmarks and the results were encouraging - 51 min gain over standard rockbox. I'll have to redo the tests, though as the flash drive that had the files is now fried. 19.55.46 # kugel: the SansaFuze page is "a little" misleading. is the bootloader process the same as on clip? 19.57.50 Join miepchen^schlaf [0] (n=miepel@p579ECB62.dip.t-dialin.net) 20.00.26 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 20.00.39 # Zagor: yea 20.00.57 # Zagor: I actually have never looked at the SansaFuze page. 20.01.03 # :-) 20.01.08 # the SansaV2 page contains a generic bootloader installation 20.01.28 # Bagder: can we add some more information to the build-info file for the dailies? I was thinking of a section [release] with player=version list 20.02.04 # that way rbutil could easily get the information about the latest release, and we don't need to download another info file 20.03.29 # gevaerts: Is says thusly: The list shall contain only well known logical units, if any. If there are no well known logical units, the LUN LIST LENGTH field shall be zero. 20.05.13 # bluebrother: that won't work on a new install would it? 20.05.15 Quit jhulst (Read error: 110 (Connection timed out)) 20.05.38 Quit kugel (Read error: 110 (Connection timed out)) 20.06.03 # rasher: why not? We have the player shortname from the autodetection, and h100=3.1 is quite explicit enough 20.06.28 # plus, not finding the player would implicitly indicate that there hasn't been a release at all ... 20.06.31 # oh wait, ignore me 20.08.04 Join {-phoenix-} [0] (n=dirk@p54B47538.dip.t-dialin.net) 20.09.22 # jhMikeS: "Support of the REPORT LUNS command on devices having only a single logical unit with the logical unit number of zero is optional.". That doesn't make this trick impossible, but I can imagine some OSes not liking devices with one LUN that's not 0. Also, I'm not sure if REPORT LUNS is always called by all OSes 20.09.54 Join Lear [0] (n=chatzill@rockbox/developer/lear) 20.12.18 # gevaerts: Wasn't the idea to present a HID for charging-only usb operation? 20.12.34 # amiconn: it was, but jhMikeS is apparently exploring other paths :) 20.12.49 # gevaerts: I'm trying to find _something_ here to give a nice effect (without strange types of drives showing up). :) 20.13.49 # If that's really the nicest way without delving into the obscure, what sort of HID would it be anyway? 20.13.51 Join mib_xzuq6s2n [0] (i=cf6be8f5@gateway/web/ajax/mibbit.com/x-2f6f80f9dcb32d07) 20.14.15 Nick mib_xzuq6s2n is now known as MarcGuay (i=cf6be8f5@gateway/web/ajax/mibbit.com/x-2f6f80f9dcb32d07) 20.16.07 # jhMikeS, toffe, Davide-NYC: My beast has been recovered using the v1.2 updater at work (must be an MTP problem on the home PC). I know you were all very concerned. 20.16.52 # Can someone tell me if it's normal behavior for the hold button to pause a plugin app and or turn the screen backlight off. I'm looking at bubbles and blackjack on an e200v2 and yes I looked through the manual.... 20.17.25 # MarcGuay: Sweet. Actually, Davide-NYC wasted to send me his beast in the mail. Perhaps he should be made aware of this. 20.18.00 # jhMikeS: Send him an email. 20.18.13 # Sure thing. 20.18.53 # jhMikeS: I'd expect a keyboard with no actual keys or some such thing 20.19.40 # A bit analogous to FS#8747 (except it would be HID of course) 20.20.30 # jhMikeS: I think he managed to recover his using the updater and then reinstalled a dual-bootloader and had even weirder problems. 20.21.00 # make the ipod scrollwheel work as a mouse? ;-) 20.21.58 # bluebrother: default should be strictly do-nothing I think. Options to do a lot more are of course welcome :) 20.21.58 # Is that even remotely possible? Does the wheel detect stationary contact or only sliding? 20.22.20 # FlynDice: Yes. Hold is pause in Rockblox as well. 20.22.49 # should it turn off the LCD backlight also? 20.23.08 # gevaerts: I agree on the default. But having it doing something useful would be nice nevertheless ;-) 20.23.09 # FlynDice: The backlight settings are controlled by Settings->General->Display or similar. 20.23.22 # archivator: mice don't need to report absolute position. You use the select button to switch between X and Y :) 20.23.30 # imagine you can scroll through the slides on your powerpoint presentation using an ipod ... 20.24.06 # Or play doom on your PC using the controls you're used to :) 20.24.26 # gevaerts: nah, that's counter-intuitive. If the wheel can detect stationary touch, then it can be turned in a 4-button control without using the actual buttons. 20.24.38 # archivator: it can't 20.26.10 # I can report that changing div without bypass actually works 20.26.13 # gevaerts: is there a USB display standard by chance? 20.26.14 # gevaerts: that's too bad. Second best approach would be to hold the buttons.. 20.27.03 # Llorean: not that I know of 20.27.08 # gevaerts: I thought the iPod wheel can detect stationary touches 20.27.12 # We used that in Rockboy I thought 20.27.47 # I just remembered - Llorean's right, that's how I play Mario Bros. 20.27.48 # the clickwheel can but not the older ones (IIRC) 20.27.56 # Makes sense 20.27.57 # I think it can. The sansa can't however 20.28.02 # The sansa certainly can't. 20.30.17 Quit MarcGuay ("http://www.mibbit.com ajax IRC Client") 20.32.51 # bluebrother: The clickwheel can, with the exception of the Mini G1 20.36.31 # and now I see that we already change PLLCR without bypass, in pcm-coldfire.c 20.37.08 Join akur [0] (n=akur@bl9-152-157.dsl.telepac.pt) 20.37.23 Part akur 20.37.38 # I'll post my patch 20.38.11 # Zagor: Maybe that's the cause for the occasional hard lockup? 20.38.21 # who knows 20.38.35 # I get that every now and then (about every other day on average) 20.38.58 # Quite annoying on the H1x0 :\ 20.39.18 # good. change coldfire_set_pllcr_audio_bits() to wait for PLL properly and we'll find out. 20.39.47 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 20.40.04 Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-dd08c6d12884c47d) 20.40.40 # It seems to be more likely with voice enabled, and no music playing 20.41.15 # It happens during directory browsing 20.41.18 Quit Jaykay_ (Read error: 110 (Connection timed out)) 20.42.28 # if it happens that often, a test should be rather revealing. I only use my H140 for development so I have never encountered that problem. 20.43.19 # Currently I'm using the H180 a lot, and most often in the car (== voice enabled) 20.43.19 # is this something other users get too? I would have thought there would be an uproar if one of our supported targets hangs every other day. 20.44.12 # This bug is present for a really long time 20.44.33 # for you or for others? 20.45.04 # For me. I should check whether other coldfire targets are also affected, it's just that the H180 is the best among them imo 20.45.35 Join Davide-NYC [0] (n=Davide-N@user-12ld9li.cable.mindspring.com) 20.45.46 Quit Davide-NYC (Client Quit) 20.45.57 # I don't know - maybe others don't use voice that much 20.46.46 # I'm not only using a voice file but also .talk clips 20.47.18 # I didn't observe those lockups on arm targets so far 20.51.37 Join BXCracer [0] (n=bxcracer@78-62-4-159.static.zebra.lt) 20.52.35 Join at0m [0] (n=a548c80b@gateway/web/cgi-irc/labb.contactor.se/x-5a5119a6c0856a87) 20.53.51 # rockbox-trunk-svn/apps/recorder/bmp.c:184:23: warning: integer constant is too large for its type 20.53.59 # that's weird. 20.54.19 # the line is: unsigned char buf[BM_MAX_WIDTH * 4]; 20.54.28 *** Saving seen data "./dancer.seen" 20.54.38 # and BM_MAX_WIDTH is 28 20.57.04 # Zagor: I also saw these lockups sometimes on my M5 - also using voice file (no .talk clips though) and usually they happen in the file browser for me too, didn't happen very often to me lately though 20.57.17 # Zagor: coldfire_set_pllcr_audio_bits is only called for initialization and when there's an actual sample rate change. 20.58.02 # do voices run at 44k1? 20.58.31 # hey lucent 20.58.39 # Afaik everything is resampled so far 20.58.41 # Zagor: everything does 20.59.08 # But even if it is, the init still writes to PLLCR, potentially causing a glitch if not setting the bypass bit first 20.59.19 Join gregorovius [0] (n=diego@host195.190-226-187.telecom.net.ar) 20.59.22 # would be nice if you could test the bunch of test bitmaps Unhelpful provided using a SVN build (I'm busy right now with resolving some storage regression) 20.59.36 # amiconn: a glitch that causes a freeze minutes/hours later? that is _very_ far-fetched. 20.59.45 # amiconn: even if preserving non-related bits? 20.59.47 # kugel_: yeah, where are they? I'll be happy to test 21.00.37 # http://unhelpful.cleansoap.org/test-bitmaps.zip 21.00.38 # Zagor: Immediately. I didn't check the code, but I think the init is called every time the pcm is restarted after running out of data 21.00.46 # jhMikeS: yes 21.01.09 Part archivator ("Leaving") 21.01.16 Join archivator [0] (i=archivat@77.70.28.57) 21.01.17 # kugel_: okay, and instructions for testing, load them in rockpaint or something? also which keypress do we have mapped on fuze to do this? 21.01.27 # And that running-out-of-data and restart probably happens quite often when browsing with voice enabled 21.01.37 # yes, loading them in rockbpaint 21.01.44 # the pcm filters for an actual change, so if pcm_set_frequency didn't actually change the samplerate value, it is skipped 21.02.15 # hold select, goto open with and select rockbpaint 21.02.15 # pcm_play_dma_init() does not filter 21.02.15 # go to ;) 21.02.15 # okay thanks 21.02.31 # amiconn: well, just try to change it and we'll find out. there's no use guessing. 21.02.40 # amiconn: where's that being called repeatedly? It's supposed to be startup code only. 21.02.53 # my impression was that the quicker I browse the more likely such a lockup could happen, haven't been able to reproduce at will 21.03.37 # jhMikeS: it's not. it is only called at startup. 21.04.43 # kugel_: I'm holding select and it doesn't do anything? 21.05.03 # main() -> audio_init() -> pcm_init() -> pcm_play_dma_init() -> coldfire_set_pllcr_audio_bits() 21.05.11 Quit tyfoo (Read error: 131 (Connection reset by peer)) 21.05.12 # eh? it should open the context menu (and it does here) 21.05.43 Join tyfoo [0] (n=tyfoo@dyndsl-095-033-037-154.ewe-ip-backbone.de) 21.06.25 # kugel_: negatory, rockpaint will toggle between drawing or not drawing on select button, but it does no action on holding the select button. Then, after a time of not pressing any button, the device powers off 21.06.39 # so sorry I am unable to test as described :( 21.06.43 # oh you are already in rockpaint? 21.07.15 # yeah 21.07.16 # I thought you asked how to open it in rockpaint 21.07.28 # I got confused, I didn't know there is a context menu 21.07.34 # now I understand what you said and will test 21.07.50 # it should work as you described but I was confused :) 21.07.54 # Zero-wait boost for Coldfire: FS#9797 21.08.21 # lucent: well, just look if the images are corrupted (ignoring the banding I assume) 21.08.36 # and thanks to my keymap of failure you can exit with the power button 21.08.53 # * lucent cheers 21.10.04 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 21.11.02 # Zagor: nice, I hope that opens the doors for some gui boost? 21.11.22 # kugel_: rockpaint does power off the device after a few seconds though 21.11.31 # or there's a bug of some kind 21.11.38 # are you using SVN? 21.11.41 # it might be that "power button press" due to wheel stuffs 21.11.42 # yeah 21.11.43 # kugel_: yes, if we deem it safe. it requires a lot of testing first though, since it's not the documented way 21.11.48 # i.e. without any of Unhelpful patches 21.11.54 # yes 21.12.18 # maybe that's part of the bug we try to resolve with the image corruption? ;) 21.12.24 # :) 21.13.15 # Zagor: have you touched the clip recently? My clip fights with some SD bug that causes it to write corrupted files (they're entirely zeroed). Apparently, LambdaCalculus37's too 21.13.22 Quit japc (Read error: 110 (Connection timed out)) 21.13.46 # weird is that it doesn't seem to happen on the fuze 21.13.54 # yeah I heard. it hasn't struck me yet though. 21.14.33 # I'm using svn+svn bootloader. maybe your bootloader is old enough to prevent that? 21.14.47 # maybe... 21.14.49 # even thouh I don't really think the bootloader changes anything 21.15.07 # we shouldn't rely on the bootloader to set things up anyway 21.16.01 # and, IIUC, we don't, except for setting up the RAM 21.16.05 # on ams 21.16.29 # I'll try updating my fuze bootloader, that one is rather old. if that introduces the bug, we know where to start 21.16.41 # wait, what' i do now? 21.16.51 # and what happened with the images? 21.17.08 # Gigabeast terribly guilty of relying on the bootloader to do that at this point 21.17.39 # kugel_: actually it looks like system_init() in system-as3525.c does a number of things, including clock setup, in the bootloader only 21.19.18 # Sometimes with LCD code, reinit in the firmware care cause ugly display glitching. 21.20.48 Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) 21.21.12 # fuze is fine 21.21.42 # maybe something is bad with my fs? even though I'm unsure how often I need to format it to get it working :/ 21.21.58 # I already did a dozen times 21.22.49 Quit robin0800 (Read error: 60 (Operation timed out)) 21.24.13 # jhMikeS: you know what bugs me? that the buttonlight/wheellight timeout is so far away from backlight timeout 21.25.00 # I'd welcome if those light settings would get their own menu, they're not necessarily connected to the lcd (besides making it visible) anyway imho (i.e. actually a different part of the hardware) 21.27.29 # kugel_: the banding effect begins when loading test-172 21.27.46 # no problem when loading test-164 21.28.15 # lucent: hm, interesting, that might be the border. my 150x150 don't show corruption either 21.28.19 # Unhelpful: ping? 21.28.36 # lucent: any other obvious corruption? maybe compare with a pc app showing them 21.28.56 # kugel_: the test-212 does show those weird individual pixel values 21.29.06 # I haven't tested between 180 and 212 yet 21.29.51 # * kugel_ notices another thing which makes the buttonlight work: press a button long enough 21.30.20 Quit karashata ("G'bye everyone!") 21.33.49 # kugel_: apparently only test-212 has "bad pixel value" problem for me 21.34.23 # kugel_: there's one suspect pixel value I notice on test-204, but it is consistent with the banding issue 21.35.31 # kugel_: buttonlight works at all? I do not see any button light on my Fuze in rockbox since you updated the better working wheel code 21.36.41 # possibly the 220 one too if there was one 21.36.56 # lucent: it's not in svn yet 21.37.17 # I'm still investigating why it doesn't work as it should 21.38.06 # there is a 220, isn't there? 21.38.11 # didn't see one, let me check again 21.38.18 Nick kugel_ is now known as kugel (n=chatzill@e179038065.adsl.alicedsl.de) 21.39.01 # Unhelpful: I don't see a 220 did you pack one in the archive? 21.39.37 Quit nuonguy ("This computer has gone to sleep") 21.40.03 # * kugel sees Unhelpful failed at batch'ing 21.40.08 # :P 21.40.16 # results are (004,108,156,164) = OK; (172, 180, 188, 196, 204, 212) = banding; 212 = bad pixel values noticable 21.40.58 # I tried batch-building rockbox.zip's with different values of BM_MAX_WIDTH 21.41.19 # it failed to build after BM_MAX_WIDTH 26 21.41.28 # I mean, BM_MAX_WIDTH 28 fails to build 21.42.41 # it was due to an error in my script 21.42.43 # =P 21.42.54 # #define BM_MAX_WIDTH 51210080604020098969492908886848280787674727068666... 21.43.02 # whoops, bad sed substitution! 21.46.17 Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) 21.46.53 # * kugel sees lucent fails at batching too 21.46.56 Join m0f0x_ [0] (n=m0f0x@189-47-48-230.dsl.telesp.net.br) 21.50.46 # * kugel notices another wheel light problem 21.52.27 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 21.52.54 Join MethoS- [0] (n=lem@host-091-096-213-039.ewe-ip-backbone.de) 21.53.56 Join gregzx [0] (n=chatzill@dsx2.neoplus.adsl.tpnet.pl) 21.54.50 # here we go again, I'm queuing up another batch build of rockbox, for all integer values of BM_MAX_WIDTH from 1 to 212 21.57.06 Join tessarakt [0] (n=jens@e180079131.adsl.alicedsl.de) 21.59.03 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 21.59.08 Quit m0f0x (Read error: 110 (Connection timed out)) 22.03.46 Quit gregorovius (Read error: 110 (Connection timed out)) 22.04.24 Join gregorovius [0] (n=diego@host16.190-30-157.telecom.net.ar) 22.09.56 Quit thegeek ("( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )") 22.12.01 Join fenugrec [0] (n=ABC@modemcable247.111-201-24.mc.videotron.ca) 22.12.49 # Anyone wants to trade a v2 Sansa for my v1 e260 (4GB) ? 22.13.26 # hmmm 22.13.45 Join gregzx_ [0] (n=chatzill@dsl211.neoplus.adsl.tpnet.pl) 22.14.00 # fenugrec: the clips are dirt cheap 22.14.12 # fenugrec: I also encourage you to get a clip 22.14.15 # yeah, but I wanted an e2xx 22.14.21 # ah 22.14.31 # but why v2? 22.15.28 # I wanted to mess around with the new Rockbox port, so I bought this e260 on ebay (I was hoping it would be a v2) 22.16.09 # unless you need microSD slot support, the Clip is a great player 22.16.20 # it's a Sansa AMS i.e. the new port 22.16.33 # clearly i failed @ batching :/ 22.17.00 # Unhelpful: I'm batching some builds of rockbox with the patch for BM_MAX_WIDTH now 22.17.08 # * Unhelpful points out that 26 isn't a multiple of 8 ;P 22.17.13 # Zagor: 24 mhz seems a bit low, what's the next higher possibility? 22.17.18 # ah that's it - the microSD was definitely something I didn't like about the clip 22.17.40 # *lack of microSD 22.17.48 # fenugrec: the other target in active development and easily available is the Fuze 22.18.27 # preglow: Well, it encourages getting GUI boosting working 22.18.59 # Unhelpful: does BM_MAX_WIDTH have to be a multiple of 8? 22.19.10 # I know that's what you suggested to do earlier, I did not ask why 22.19.23 # preglow: if you've got zero cost boosting, 24mhz is perfect 22.19.43 # fenugrec: Are you planning on doing development work? As a user, Rockbox is essentially the same on most players so a new port is pretty similar to an old port. 22.19.45 # ok. Well, I didn't want to spend much more money, so I as hoping there might be some people who wanted a v1 (because of the much more complete Rockbox port) 22.19.46 # then the GUI code can just boost whenever it runs and you'll save a lot of power verses keeping it at 45mhz all the time 22.19.51 # saratoga2: true enough 22.20.22 # fenugrec: try on the forums. People here are likely to have a v2 if they want one :) 22.21.25 # Llorean: I won't pretend I can do much development, I just wanted to do some hacking on an mp3 player, the v2 was quite interesting to me and inexpensive) 22.21.26 # the read loop unrolls up to 8px at a time, in the case of mono bitmaps. 22.21.38 # Yeah, I guess the developper channel isn't quite the right place to ask 22.22.05 # fenugrec: You may be better off with a developed port. You can still hack on it in the form of coming up with new features, etc, while not having to deal with the incompleteness in areas you may not be able to actually complete. 22.22.08 # it's also the support channel... 22.22.21 Quit {-phoenix-} (Remote closed the connection) 22.22.42 # preglow: yes 24MHz is a bit low for now. but if we implement zero-wait boost we can use lots more small boosts for example in lcd_update, so a lower base frequency is likely possible. 22.23.14 # here's the 220px image: http://unhelpful.cleansoap.org/test-220.zip 22.23.22 # Unhelpful: okay, will test 22.23.46 # Llorean: sure, if I end up keeping my v1 I'll be able to try some stuff with it. but I wanted a v2, boo-hoo.. :-( 22.24.13 # actually it's 22Mhz. I wrote wrong. 22.24.19 # fenugrec: A v2 basically means "it's harder to hack on because you don't know if the bugs are your own, or due to things not being complete yet" unless you're planning on working on low-level stuff yourself. 22.24.28 # Unhelpful: Did you see my question? 22.25.53 # amiconn: the fixed-size array did not take into account that greylib might round up the display width or height 22.26.40 # Ah, didn't think of that detail (even though I coded it...) 22.27.08 # Zagor: the whole argument of boosting being free had me sold anyway, it doesn't matter too much :) 22.27.30 # it was just based on what i'd measured as the used size on one target... greylib init would likely fail on some 22.29.29 # what was the technical obstical to free boosting on PP? 22.29.51 # Llorean: I did intend to do some probing with my scope, & other fairly low-level stuff (there's perhaps still some hardware work to do on the v2, i.e. for the buttons? JTAG support was also something I wanted to test..) 22.29.56 # Hmm, actually it's not only the padding of width/height, but also alignment 22.30.02 Quit gregzx (Success) 22.30.03 Quit TheSphinX^ ("XChat@Linux") 22.30.11 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 22.30.30 # saratoga2: We're still not sure it's possible. Right now clock switching on PP requires syncing cores 22.30.49 # I hpoed that jhMikeS could tell us why this is necessary (he added it) 22.31.09 # and current draw / battery tests... 22.32.43 # (I need to get up to date as to the status, last time I read the v2 thread was in November - I suspect much has happened in 2 months) 22.32.45 # fenugrec: if you really want a v2, offer a swap on the user list. I'd be surprised if nobody takes you up on that. 22.33.05 # user list => mailing list ? 22.33.09 # fenugrec: yes 22.33.41 # Ok, I'll try that (thanks for the tip I didn't know there was a mailing-list) 22.33.45 # fenugrec: here http://stores.ebay.com/OutletMP3_MP3-player_W0QQcolZ4QQdirZ1QQfsubZ2QQftidZ2QQtZkm is where I bought an e280 few weeks ago. I just added as note, if they don't mind to check for v2. At end I had one, but I don't know if this related to my message (since they didn't reply me personnaly). I'm sure you will check an ebay seller that can see if this is a v2... 22.34.48 # moos: thanks, I'll check that out too 22.35.10 # no problem 22.35.16 Quit kugel (Read error: 110 (Connection timed out)) 22.36.20 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 22.36.43 # there is a new Rockbox port for v2? 22.36.46 # hu?! 22.37.04 # in progress, yeah 22.37.07 # yeah 22.38.00 # we're approaching FS # 10K fast ... 22.38.08 Quit archivator ("Leaving") 22.38.13 # tessarakt: for recent info, you will probably be better off checking the forum thread in the new topics forum 22.38.31 # you know what I am missing? 22.38.43 # we refer to "v2" as AMS sansas these days 22.38.51 # A German distribution charity for free software 22.39.19 # where you say "Give money to ..." and you get a tax-deductible receipt ... 22.40.51 Quit bertrik ("Leaving") 22.43.57 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 22.47.29 # boost is definitely broken on clip 22.50.43 # Do you need any more testers for e200v2? I have a e260v2 with the latest button patches. Scroll wheel still doesn't work. Are there any patches for the wheel yet? 22.50.57 # saratoga2: did you have time to do your measuring magic? 22.51.33 # Zagor: i'm trying right now 22.51.45 # if it works i'll let you know, but i'll have to leave in a few minutes due to work 22.51.52 # ok 22.53.24 Join merbanan [0] (n=banan@83.233.243.20) 22.54.30 *** Saving seen data "./dancer.seen" 22.54.54 # grrr file too large error due to left over bits of test_codec 22.55.12 Quit jeffronius ("KVIrc 3.2.6 Anomalies http://www.kvirc.net/") 22.55.20 # jeffronius: highly visible bugs like these don't really need testing. thanks anyway. 22.57.39 Quit grndslm ("Leaving") 22.58.16 Quit nplus (Remote closed the connection) 22.58.26 # I get 200.00MHz 22.58.27 Quit HBK (Read error: 110 (Connection timed out)) 22.58.51 Quit XavierGr (Nick collision from services.) 22.59.02 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 22.59.30 # Zagor: on fuze that is 22.59.35 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 23.00.22 # is that what you expected? 23.00.56 # I don't know :-) I just know it didn't change. But I have fixed it now. 23.02.35 # the mp3 skipping issue looks like a pcmbuf bug. it's jumping all over the place. 23.04.56 # however my 320kbit test tracks work a lot better with working boost. still buggy, but much less. 23.05.02 # Unhelpful: I am prevented from viewing the output that rockpaint loads with test-220 because of some hideous bug that exits rockpaint 23.05.12 # * lucent stabs, kills, stabs again 23.07.05 # Zagor: Imo 24MHz are too low for unboosted. I don't lik ethe reduction of the boosted frequency as well. It means that e.g. the already struggling mpegplayer (on colour coldfire targets) will be struggling even more 23.08.17 # amiconn: things will be very different if/when we use short boosts. you can't compare the speeds directly. 23.08.30 # For some cases I can 23.08.55 # we could introduce a max mode for mpegplayer. in fact I have toyed with that idea for the gigabeats too. 23.09.01 # Right now the greylib doesn't need to boost on H1x0 and M5. CPU load due to the grey isr is around 45% 23.09.33 # it doesn't matter if it needs to boost. boosting is free. 23.09.45 # that's the whole point 23.09.46 # If you halve the unboosted clock, you push the cpu load near 100% - meaning the greylib would need to boost in order to leave enough cpu cycles for the rest of the plugin 23.10.39 # And it cannot use micro-boosts, because every boost/unboost causes a bit of timer period jitter 23.10.54 # The greylib needs a stable timer for steady display 23.11.14 # And boosting is not free in terms of power consumption 23.11.19 # they greylib is an edge case. we're not designing the whole of rockbox around greylib. 23.11.42 # yes it is 23.12.39 # Why did you choose those odd clock frequencies, btw? 23.12.47 # CPUDIV offers 1..8 iirc 23.13.18 Join kugel [0] (n=chatzill@unaffiliated/kugel) 23.13.24 # amiconn: because you wrote that these are the only possible clock frequencies with properly working timers 23.13.26 # Zagor: wow, since when was that broken? 23.13.41 # kugel: no idea 23.13.50 # I mean, I always had the suspicion that boosting doesn't work, now it seems to be proven 23.13.56 Quit bluebrother (Nick collision from services.) 23.13.58 # Zagor: They are the best frequencies for properly working timers, not the only possible ones 23.14.01 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 23.14.11 # the suspicion was due to heavy slowness at the beginning of AAC playback 23.14.29 # amiconn: in any case, this is a test. we naturally should optimise this as everything else. I have not recalculated the waitstates either. 23.14.38 # This is because these are integer multiples of the base frequencies. We could use fractional ones, at the cost of loosing a little timer precision 23.15.22 # The higher the denominator of the fraction, the more timer precision we'd loose. But then PP timers use an 1MHz base, so using half-base wouldn't be that bad 23.17.37 # Hmm, #9797 is only for irivers, not for iaudios 23.17.51 # oh, mistake 23.18.28 # I'll just edit the description. 23.18.55 # nah, add a comment and then fix the patch tomorrow 23.18.59 # iAudios have 2 system-*.c files, one for MCF5250 (M5/X5), and one for MCF5249 (M3) 23.20.03 Quit XavierGr () 23.21.28 # Bagder: did you see my hilight earlier? 23.21.59 # yeah, but I'm a bit occupied tonight with other duties so I selected to ignore it for now :-) 23.22.25 # ok ... you think it's a feasible way to go? 23.23.02 # sure 23.23.43 # nice. Lets look into that another day then. 23.25.32 # * amiconn wonders whether 120MHz and 30MHz (actually 120.4224 and 30.1056 MHz) would be nice CPU clock frequencies for coldfire 23.28.12 Join Willwolfe [0] (n=chatzill@net35-14.netkaster.ca) 23.29.24 # if i would start and try to port rockbox to a player, after i gather information on the player would the next step be to edit tools/config? 23.29.59 # TheSkunkMan: www.rockbox.org/wiki/NewPort is the first basics 23.30.05 Quit bmbl ("Woah!") 23.30.59 # then http://www.rockbox.org/twiki/bin/view/Main/PortingHowTo 23.31.25 # thats what I was doing right now 23.32.32 # what i didn't understand was the tool and toolset variables 23.33.00 # tool is what is used to produce the binary that the bootloader loads 23.33.23 # toolset is a list of all tools needed to build a full rockbox for the target 23.33.44 # ... available in the tools/ dir 23.34.18 # TheSkunkMan: have you figured out the OF file format already? 23.34.33 Quit evilnick ("http://www.mibbit.com ajax IRC Client") 23.34.52 Quit Willwolfe ("ChatZilla 0.9.84 [Firefox 3.0.1/2008070208]") 23.38.25 Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) 23.40.27 # saratoga2: [19:01:19] in case anyone is wondering, the e200v1 boosts to 79.71MHz +/_ the accuracy of our timers 23.40.57 # ^ Did you reinvent the wheel? There's a performance estimation based on loop execution speed in the debug menu for PP targets 23.40.58 Quit domonoky (Read error: 54 (Connection reset by peer)) 23.41.17 # Zagor: hm, sadly, behavior didn't change with your boosting fix 23.41.29 # still major slowdown on aac 23.41.46 # ok 23.43.13 # amiconn: it seems you don't have an opinion on the backlight fading discussion? 23.43.35 # I do, but I'm really lazy when it comes to writing mails :( 23.44.02 # no mail, no opinion ;-) 23.44.16 # * Bagder leans back with no opinion 23.44.55 Join akur [0] (n=akur@bl9-152-157.dsl.telepac.pt) 23.44.56 Part akur 23.45.14 # :) 23.45.46 # there's where my expertise lies 23.46.57 Quit tyfoo ("Carpe diem") 23.47.31 # TheSkunkMan: Generally the first step on a new port is to figure out the firmware upgrade process, and to work out how you will run your own code in a safe way (i.e. a way you can recover from when it inevitably crashes). You can do this outside the Rockbox code. 23.47.37 # Zagor: can you confirm that boosting is working now, besides that mp3 runs better? 23.48.09 # kugel: yes, my boost test plugin shows this very clearly 23.48.23 # <_Auron_> efnet is on a farting spree 23.48.29 # oh, can you share that maybe? 23.48.36 # sure, I'll commit it 23.48.41 # even better 23.48.42 # <_Auron_> oops wrong chan :P 23.49.58 # seems quite a lot of people don't have an opinion on the backlight fading thing :o 23.50.07 Quit tessarakt ("Client exiting") 23.52.33 # kugel: committed 23.53.47 Quit BXCracer (Remote closed the connection) 23.55.41 Quit Lear ("ChatZilla 0.9.84 [Firefox 3.1b3pre/20090109073009]") 23.56.38 Join xz [0] (i=d984c4e2@gateway/web/ajax/mibbit.com/x-1d97ef629b83c60e) 23.57.46 # nice