--- Log for 01.03.109 Server: grisham.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 24 days and 7 hours ago 00.05.59 Join SirFunk_ [0] (n=Sir@208-15-25-145.netsync.net) 00.08.30 Quit podliy () 00.09.57 Quit {phoenix} (Remote closed the connection) 00.14.07 Join Thundercloud [0] (n=thunderc@82.132.136.189) 00.17.19 Quit pixelma (Nick collision from services.) 00.17.20 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 00.17.22 Quit amiconn (Nick collision from services.) 00.17.25 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 00.17.34 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 00.17.43 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 00.18.50 Quit flydutch ("/* empty */") 00.21.04 Quit SirFunk__ (Read error: 110 (Connection timed out)) 00.30.17 Quit fml ("CGI:IRC") 00.34.02 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 00.35.56 *** Saving seen data "./dancer.seen" 00.48.28 Quit bluebrother ("leaving") 00.57.30 Quit Beta2K (Read error: 110 (Connection timed out)) 00.59.00 Quit miepchen^schla () 01.06.02 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 01.13.51 Quit tim__b (Remote closed the connection) 01.19.46 Quit bmbl ("Woah!") 01.20.19 Quit ender` (" A bus station is where the bus stops. A train station is where the train stops. On my desk, I have a workstation.") 01.26.01 Quit mcuelenaere () 01.27.57 Join bs66_ [0] (n=sysuser@79.138.203.117.bredband.tre.se) 01.31.18 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.32.26 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 01.42.55 Quit Thundercloud (Remote closed the connection) 01.42.59 Quit bs66_1 (Read error: 110 (Connection timed out)) 01.47.09 Join nibbler [0] (n=Nibbler@pD9E31C17.dip.t-dialin.net) 02.00.07 Join krazykit` [0] (n=kkit@adsl-76-252-12-197.dsl.ipltin.sbcglobal.net) 02.00.07 Quit krazykit (Read error: 104 (Connection reset by peer)) 02.02.03 Quit tyfoo (Read error: 104 (Connection reset by peer)) 02.05.08 Join krazykit [0] (n=kkit@adsl-76-252-12-197.dsl.ipltin.sbcglobal.net) 02.07.18 Join z35_ [0] (n=z35@h200.80.91.75.dynamic.ip.windstream.net) 02.07.56 Quit krazykit` (Read error: 60 (Operation timed out)) 02.10.43 Quit nibbler (Read error: 110 (Connection timed out)) 02.12.15 Quit z35 (Read error: 60 (Operation timed out)) 02.15.23 # linuxstb: ping 02.16.58 Quit Llorean (Read error: 104 (Connection reset by peer)) 02.17.19 Nick z35_ is now known as z35 (n=z35@h200.80.91.75.dynamic.ip.windstream.net) 02.18.42 # Anyone here experts on the Gigabeat S install? 02.19.47 # What's the issue? 02.21.01 # I used the Windows beastpatcher and it works, except when I shutdown and start it back up it doesn't work 02.21.17 # more info please 02.22.24 Join Llorean [0] (n=DarkkOne@ppp-70-243-32-116.dsl.hstntx.swbell.net) 02.24.20 # the rockbox bootloader is installed and rockbox boots after the beastpatcher quits, but after turning the Gigabeat off and turning it back on it asks to restore or update the firmware 02.24.43 # single or dual-boot bootloader? 02.24.54 # single bootloader 02.25.59 # When was the bootloader built? 02.28.49 # I just used the windows beastpatcher provided by linuxstb, I don't know when the bootloader inside it was built 02.29.23 Join Beta2K [0] (i=1000@d36-124-26.home1.cgocable.net) 02.29.29 # I'm wondering if the on-the-fly partition fixing is upsetting the OF 02.29.45 # maybe I should try sendfirm instead? 02.30.01 # BigBambi: Wouldn't it upset the OF independent of bootloader version? It's in the main build too, right? 02.30.18 # How could it? 02.30.26 # I can't imagine how it would 02.30.32 # Unless it failed to restore it, possibly 02.30.40 # Well, it's never written though, ignore that 02.30.45 # Me neither, I'm just speculating 02.31.10 # perrikwp: There is a older single bootloader (nk.bin) on the wiki that you can install with sendfirm and see if there is any difference 02.31.55 # Llorean, gevaerts: I'm not blaming that at all - I just haven't seen this issue before and there have been some recent bootloader changes 02.32.56 # ok, i'll try it, give me a sec to test it 02.33.00 # Still, as you say, unless something changes the disk/partitioning/etc., the OF shouldn't care 02.33.20 Quit planetbeing (Remote closed the connection) 02.34.45 Join planetbeing [0] (n=planetbe@67-207-128-206.slicehost.net) 02.35.57 *** Saving seen data "./dancer.seen" 02.57.21 Join miepchen^schlaf [0] (n=miepel@p579EC563.dip.t-dialin.net) 02.58.05 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 03.03.49 Join Darksair [0] (n=user@125.33.194.226) 03.04.47 Quit n1s (Remote closed the connection) 03.07.34 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 03.08.03 # there's a theory that newer beast flash does not like the single-boot bootloader. 03.13.03 # ok I tried the older bootloader and sendfirm from the wiki and I have the same problem 03.13.21 Quit Nico_P (Remote closed the connection) 03.13.45 # so I should try making a dual-boot bootloader to see if that fixes the problem? 03.16.39 # perrikwp: it's solved *some* users' troubles with forced restores 03.18.33 Quit Xerion (Read error: 104 (Connection reset by peer)) 03.19.27 # Unhelpful: Am I to understand now that some beasts force restore no matter single or dual? I haven't heard of this suggested until now. 03.20.25 # jhMikeS: no, the some is due to the fact that i never heard again from some of the problem cases that they had solved it, or how. dual may very well have worked for them. 03.28.07 # ok I'm going to make a dual bootloader and see what happens 03.29.56 # Unhelpful: I guess I'll make a patch with a large word fill to create a big bootloader and ask someone to test to see if that makes any difference. 03.30.33 Quit miepchen^schlaf () 03.31.56 # is there a checksum that has to be correct, so that we can't just pad the "normal" bootloader binary with zeroes? 03.32.39 Join miepchen^schlaf [0] (n=miepel@p579EC563.dip.t-dialin.net) 03.34.00 # If we _have_ to, I suppose those fields would need an update from the beastpatcher. I wouldn't fill by default. I don't want to get ahead of myself but I don't know where else to start. 03.39.13 # so, *if* that works, beastpatcher would take an unpadded bootloader, and for "single-boot" installs, modify the checksum header fields as needed and pad the end with NULLs? 03.44.15 # I think. The bootloader is in that funky wince format that I'm not too familiar with. Of course I hope it's really that simple (maybe it wants something fancy). 03.55.05 Join steve6446 [0] (n=3ab2cbef@gateway/web/cgi-irc/labb.contactor.se/x-eea7ac4daa314a5a) 03.55.10 # hi 03.56.31 # i can imagine that some format oddities might lead to trouble if the padding is not part of a defined section.... best test is to try it, i've been meaning to flash my beast up to 1.2 and play around with it, maybe tomorrow night. 03.56.42 # i have a gigabeat f60 i just installed rockbox on it with the rockbox utility and my gigabeat keeps loading the original firmware is there a way to force it to load rockbox? 03.57.36 # if it keeps loading the original firmware, then the installation is not complete 03.58.34 # it says its completed 04.03.05 # Unhelpful: I'm filling using the .lds so that shouldn't be a problem here 04.05.26 # how do I use mknkboot? 04.05.30 # This will zero fill the bl to be about 12MB (like OF): http://jhmikes.cleansoap.org/gigabeat-s-padded-bootloader.patch 04.06.20 # If that works, I guess a binsearch would find a minimum size. 04.07.51 # perrikwp: theres instructions on the wiki 04.08.01 # oh sorry wrong program, never mind 04.09.02 Join moos [0] (i=Mustapha@rockbox/staff/moos) 04.09.09 # nevermind I found the instructions, thanks 04.10.15 # jhMikeS: thanks for the link, i'll try to get to it tomorrow 04.12.05 Join blkhawk- [0] (n=blkhawk@f051043109.adsl.alicedsl.de) 04.12.05 # If I'm feeling less lazy, I'll try to see if that rom can't be dumped to find out _exactly_ what make it pass. 04.12.32 # it would be nice if we could get rb bootloader in ROM ;) 04.12.40 # can the ROM be patched easily? 04.12.46 # or is it complicated like on the F 04.13.07 # I really can't say at this point. I've not looked at that aspect yet. 04.13.45 # I'd love to have it as FAT32 all the way and no retailos at all...that would be nice. 04.14.12 Join rocko [0] (n=rocko@c-67-167-117-152.hsd1.il.comcast.net) 04.15.19 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 04.22.40 # or even just patch the OF bootloader to not touch the disk 04.22.47 Join gartral [0] (n=gareth@adsl-75-33-91-251.dsl.bcvloh.sbcglobal.net) 04.27.49 # anyone, saratoga in particular, did I really insult R.L. Horn on the user mailing list or not? 04.27.55 # Insulting was not my intent. 04.28.41 # I thought I went to great lengths to stress my uncertainty as to what was going on and that I was probing for more info. 04.28.44 Quit blkhawk (Read error: 110 (Connection timed out)) 04.29.03 Nick blkhawk- is now known as blkhawk (n=blkhawk@f051043109.adsl.alicedsl.de) 04.29.08 # alright, i'm having a severe case of Stupid-User-Syndrome... i cant get rbutil to install rockbox from my ubuntu machine... 04.29.23 # saratoga: what was the complication of the F? IRAM works fine on the S. I recall the IRAM problem there making things difficult. 04.29.35 # gartral, on what player? some need root 04.30.59 # jhMikeS: its been possible to patch the F's firmware for a year or two now I think 04.31.14 # i think its just considered risky since you erase it and then write a new one 04.31.56 # soap: no I don't think you did 04.32.09 # I read his exchange yesterday and honestly had no idea what the hell he was talking about 04.33.16 # krazykit: e250 v1 04.33.31 # gartral, that's one of the ones that needs root permissions 04.34.00 # oh... now i feel really dumb :\ 04.35.58 *** Saving seen data "./dancer.seen" 04.36.56 # Unhelpful: the dual-boot bootloader works, the Gigabeat S flash must not like the single bootloader 04.37.40 # perhaps the null padding idea will help with the single bootloader then 04.38.15 # i'll try out that patch tomorrow to see if it helps 04.38.22 # thanks for everyones help 04.38.47 # krazykit: umm, it does NOT need root, the file needed to be labeled as an executable... 04.38.55 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 04.39.34 Quit steve6446 ("CGI:IRC (EOF)") 04.41.55 # hopefully it won't need much padding or else it won't be much help anyway 04.43.17 # Unhelpful: this has info about the CE format http://www.xs4all.nl/~itsme/projects/xda/wince-flashfile-formats.html 04.45.46 Quit nuonguy ("This computer has gone to sleep") 04.48.27 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-d6911ea3e10aa944) 04.56.37 Quit gartral ("Leaving.") 04.58.46 Quit miepchen^schlaf (Read error: 101 (Network is unreachable)) 05.08.32 Quit HBK () 05.09.51 Quit HellDragon (Client Quit) 05.12.35 Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) 05.14.19 Join Huwawa [0] (n=HUwawa@c-67-188-123-48.hsd1.ca.comcast.net) 05.16.01 Quit Huwawa (Client Quit) 05.18.33 Join Nate3000 [0] (n=Nate3000@c-67-188-123-48.hsd1.ca.comcast.net) 05.20.42 # Hello all. 05.21.44 # Is there a way on Mac OSX to keep iTunes from starting automatically? It's making it impossible to do anything to my iPod.. 05.23.47 # Nate3000: I'm sure there is, but you'll probably have more luck on an Apple channel 05.24.44 # is anyone around here familar with the codec interface? 05.25.49 Quit Lss (Read error: 54 (Connection reset by peer)) 05.48.54 Quit HackyKid (Read error: 110 (Connection timed out)) 05.49.14 Quit Nate3000 () 06.07.04 Join midgey [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net) 06.18.58 Quit BlakeJohnson86 (Remote closed the connection) 06.20.32 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-3f96db6b86bfe23f) 06.30.09 Quit Zoxc () 06.34.08 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 06.36.03 *** Saving seen data "./dancer.seen" 06.40.45 Quit rocko ("Leaving") 06.49.12 Join CaptainKwel [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 07.01.43 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 07.06.32 Quit CaptainKewl (Read error: 110 (Connection timed out)) 07.28.25 Quit ashes ("leaving") 07.51.07 Quit Darksair ("(define zero (lambda (f) (lambda (x) x)))") 07.54.53 Quit FlynDice ("Gotta go pay the bills!") 07.57.02 Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) 07.59.04 Quit BHSPitLappy (Remote closed the connection) 08.03.41 Join Rob2223 [0] (n=Miranda@p4FDCEA91.dip.t-dialin.net) 08.12.45 Quit nuonguy ("Leaving") 08.21.59 Quit Rob2222 (Read error: 110 (Connection timed out)) 08.27.59 Join Rabbit^^ [0] (n=Rabbit^^@72-24-220-205.cpe.cableone.net) 08.29.30 # I have a Sansa View (16GB) and rockbox does not appear to install on it. Have the people at Rockbox fixed this issue yet to anyone's knowledge? 08.36.05 *** Saving seen data "./dancer.seen" 08.40.29 Quit midgey () 08.45.03 Quit Rabbit^^ ("Off") 08.46.19 Join kubiix [0] (n=511bc91c@gateway/web/cgi-irc/labb.contactor.se/x-3d2d48ca33450402) 08.47.17 Quit kubiix (Client Quit) 09.16.20 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 09.32.51 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 09.35.16 Join midgey [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net) 09.36.54 Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) 09.41.22 Join stoffel [0] (n=sfr@p57B4F9BF.dip.t-dialin.net) 09.48.48 Join flydutch [0] (n=flydutch@host25-43-dynamic.5-87-r.retail.telecomitalia.it) 09.57.50 Join goffa_ [0] (n=goffa@216.220.23.105) 10.08.59 Join n1s [0] (n=n1s@rockbox/developer/n1s) 10.14.44 Join ender` [0] (i=krneki@foo.eternallybored.org) 10.14.53 Quit goffa (Read error: 110 (Connection timed out)) 10.30.01 Quit perrikwp (Read error: 104 (Connection reset by peer)) 10.30.58 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-d19959f332aee598) 10.35.36 Quit z35 ("Leaving") 10.36.08 *** Saving seen data "./dancer.seen" 10.45.31 Quit nuonguy ("This computer has gone to sleep") 10.59.27 Quit CaptainKwel (Read error: 110 (Connection timed out)) 11.03.26 Quit Seed ("cu, Andre") 11.06.40 Quit ender` (Read error: 104 (Connection reset by peer)) 11.06.59 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 11.09.06 Join ender` [0] (i=krneki@foo.eternallybored.org) 11.09.21 Join {phoenix} [0] (n=dirk@p54B45E68.dip.t-dialin.net) 11.20.11 Quit midgey () 11.31.51 Join nibbler [0] (n=Nibbler@pD9E32B40.dip.t-dialin.net) 11.32.55 Quit Dieterbe ("thanks and bye .. maybe we meet again in the future..") 11.33.23 Join Dieterbe [0] (n=Dieterbe@213.219.137.46.adsl.dyn.edpnet.net) 11.40.12 Quit kachna (Read error: 113 (No route to host)) 11.49.10 Join Darksair [0] (n=user@125.33.194.226) 11.50.22 Join casainho [0] (n=chatzill@89-181-83-86.net.novis.pt) 11.50.28 # hello :-) 11.51.04 # can someone explain me what means pcm_play_dma_get_peak_buffer() on audio target drivers? what is the intention? 11.54.37 Join tyfoo [0] (n=tyfoo@77-20-31-238-dynip.superkabel.de) 12.02.09 # linuxstb: are you there? 12.09.41 Quit stoffel ("Reconnecting") 12.09.51 Join stoffel [0] (n=sfr@p57B4F9BF.dip.t-dialin.net) 12.12.35 Join gregzx [0] (n=chatzill@dsz9.neoplus.adsl.tpnet.pl) 12.16.10 Join SmokeDog [0] (n=Fu@pool-71-112-56-68.sttlwa.dsl-w.verizon.net) 12.16.13 # herr0 12.16.15 # anyone around? 12.16.32 # i have a real question that wasn't in the faq 12.16.36 # real quicks 12.18.51 # ok i'll just shoot anyways and idle here for a bit and hope someone will message me 12.19.59 # so umm.... loading rockbox on it puts a second "os" on an ipod at that point by flashing the firmware will you loose the tracks you have on there already or will it make a seperate bootable folder and run for there instead while still keeping the tracks you have on said ipod or do you have to reload all the songs on there after said install? 12.20.35 # no you won't lose you're tracks 12.20.46 # although a backup is always a good idea 12.20.58 # s/you're/your 12.23.36 # thank you 12.24.18 # my buddy was whinning like a girl about it 12.34.57 # so my boy just tried downloading the install files 12.35.12 # (3:33:28 AM) ThaSkaMan1: http://build.rockbox.org/dist/build-ipodvideo/rockbox.zip 12.35.12 # (3:33:31 AM) ThaSkaMan1: fail 12.35.12 # (3:34:31 AM) ThaSkaMan1: http://download.rockbox.org/release/3.1/rockbox-ipodvideo-3.1.zip 12.35.12 DBUG Sent KICK SmokeDog to server 12.35.12 # (3:34:35 AM) ThaSkaMan1: both are a fail 12.35.12 # (3:34:40 AM) ThaSkaMan1: no installs 12.35.13 Kick (#rockbox SmokeDog :No flooding!) by logbot!n=bjst@rockbox/bot/logbot 12.35.13 Join SmokeDog [0] (n=Fu@pool-71-112-56-68.sttlwa.dsl-w.verizon.net) 12.36.03 # SmokeDog, please don't spam a bunch of lines like that. the problem must be on his end, as both links work for me 12.36.10 *** Saving seen data "./dancer.seen" 12.36.12 # im sorry 12.36.34 # it's late 12.37.14 # u been here long krazykit ur nick looks familiar 12.42.59 Join jaykay [0] (n=chatzill@p579E6BC1.dip.t-dialin.net) 12.43.55 # not a bunch of talkers i see 12.43.59 # .... 12.44.48 # IRC doesn't mean Instant Reply Chat. It's still quite early in the US and many of the Europeans are still at work, so please have patience. in the meantime, you should take a look at the channel guidelines 12.53.05 # Boosh! well way to take the fun out of it all kit 12.53.08 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 12.53.43 Join PaulJam [0] (n=Paule@p54BEBD7D.dip.t-dialin.net) 12.54.10 # SmokeDog: If you want to chat, there is #rockbox-community - we try to keep this channel on-topic and relatively serious (it's logged). 12.55.27 Join markun [50] (n=markun@rockbox/developer/markun) 12.55.36 # thank you for helping me out earlier my question was answered 12.58.00 Quit {phoenix} (Read error: 104 (Connection reset by peer)) 12.58.14 # is there a special reason why there is no resume support for ALAC? seeking seems to work fine. 12.58.31 Join {phoenix} [0] (n=dirk@p54B45E68.dip.t-dialin.net) 12.58.52 # linuxstb: can you explain me what means pcm_play_dma_get_peak_buffer() on audio target drivers? what is the intention? 13.00.22 # btw, i noticed that for AAC and ALAC the WPS always shows them as cbr even though i'm almost sure they are vbr. 13.01.58 Quit SmokeDog () 13.03.07 Part domonoky 13.04.11 Join HackyKid [0] (n=HackyKid@86.85.232.104) 13.11.51 # PaulJam: ALAC is definitely always VBR. I would expect CBR AAC to exist though. But yes, it does sound like a bug. 13.12.06 # casainho: No. 13.12.21 Join kachna [0] (n=kachna@r4ax178.net.upc.cz) 13.26.39 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 13.27.18 Quit __lifeless (Remote closed the connection) 13.27.35 Join __lifeless [0] (n=lifeless@94.50.161.244) 13.29.44 # Sansa C240 won't connect in ubuntu alpha5 sys log sayes http://paste.ubuntu.com/124707/ rockbox or alpha5 bug? 13.38.04 Join miepchen^schlaf [0] (n=miepel@p579EC854.dip.t-dialin.net) 13.41.39 Quit PaulJam (".") 14.19.42 Quit stoffel ("Lost terminal") 14.36.15 *** Saving seen data "./dancer.seen" 14.43.23 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 14.44.00 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 14.48.06 Join midijunkie [0] (n=Miranda@pD9544FF6.dip0.t-ipconnect.de) 14.58.57 Join MethoS- [0] (n=lem@host-091-096-215-138.ewe-ip-backbone.de) 15.01.05 Join MethoS-- [0] (n=lem@host-091-096-213-138.ewe-ip-backbone.de) 15.04.50 Join Alex00088 [0] (n=chatzill@64.24.51.51) 15.05.38 # can I put comments into my .cfg files, by simply appending a "#" symbol to a line? If not - is there a way to add comments? 15.05.51 # *prepend 15.06.56 # You could've tested in about as long as it took you to ask. ;) 15.07.35 # ok. thanks! 15.07.44 Quit Alex00088 (Client Quit) 15.10.22 Quit robin0800 (Read error: 104 (Connection reset by peer)) 15.10.22 Quit HackyKid (Read error: 104 (Connection reset by peer)) 15.10.42 Join HackyKid [0] (n=HackyKid@86.85.232.104) 15.13.05 Quit jaykay (Read error: 110 (Connection timed out)) 15.13.32 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 15.19.33 Join Thundercloud [0] (n=thunderc@82.132.136.185) 15.19.42 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 15.20.52 Quit MethoS- (Read error: 110 (Connection timed out)) 15.21.10 Quit {phoenix} (Remote closed the connection) 15.23.58 Join {phoenix} [0] (n=dirk@p54B45E68.dip.t-dialin.net) 15.26.26 Quit casainho ("ChatZilla 0.9.84 [Firefox 3.0.6/2009020911]") 15.28.49 Join stoffel [0] (n=sfr@p57B4F9BF.dip.t-dialin.net) 15.32.22 Quit avis ("maybe when we drown, the fish will be our friends") 15.37.32 Join Zoxc [0] (i=Zoxc@ti0128a340-dhcp0261.bb.online.no) 15.37.34 Quit faemir ("Leaving") 15.44.53 Join Horschti [0] (n=Horscht@xbmc/user/horscht) 15.54.58 Join avis [0] (n=ident@pdpc/supporter/student/avis) 15.55.09 Join funman [0] (i=500de41d@gateway/web/ajax/mibbit.com/x-0ed5e6652d401ef5) 15.55.27 # hello 15.58.08 Join kugel [0] (n=kugel@rockbox/developer/kugel) 15.59.04 # i'm glad to see some progress on sansav2 , i want to help on >2GB models 16.00.25 # on the web i can find a 4GB Fuze at 95€, delivered 16.00.54 # offers for the clip seem to stop at 2GB (so, not interesting since the whole 2GB are accessible) 16.01.34 # i can find 4GB but only in the US, and I expect more important shipping price 16.02.06 Quit SirFunk_ (Read error: 110 (Connection timed out)) 16.02.36 # IIRC lambdacalculus has bought a bunch of clips, is he the one? 16.02.55 Join MethoS- [0] (n=lem@dyndsl-085-016-164-227.ewe-ip-backbone.de) 16.03.02 # funman: salut, maybe see with Zagor/Bagder and the rockbox's fund it could help you.... 16.03.03 Join SirFunk_ [0] (n=Sir@208-15-25-145.netsync.net) 16.03.31 Quit Horscht (Read error: 110 (Connection timed out)) 16.04.06 # moos: merci, perhaps i'm not coming at the right time, but it's difficult here :/ I think I'll use good old email 16.08.01 Join webguest84 [0] (n=5773d21c@gateway/web/cgi-irc/labb.contactor.se/x-88c3270da1b53801) 16.09.00 Join webguest42 [0] (n=5773d21c@gateway/web/cgi-irc/labb.contactor.se/x-fa3975544427063a) 16.09.00 Quit webguest84 (Client Quit) 16.10.47 # funman: hi 16.12.47 # kugel: hi! nice work on v2 ; 16.12.49 # ;) 16.13.40 # funman: have you checked amazon? I've seen a Fuze 8G at 70EUR 16.13.45 # funman: actually, I'm more concerned about the dcache and mmu, not so about the >2GB problem 16.14.28 # our ams sansas are utterly slow, because those aren't active 16.15.08 # bluebrother: i only found v2 on amazon in $ (i used google) 16.15.42 # I looked at amazon directly -- http://www.amazon.fr/Sandisk-Lecteur-audio-video-microSD/dp/B0019JOD68/ref=sr_1_1?ie=UTF8&s=electronics&qid=1235920365&sr=8-1 16.16.27 # bluebrother: hm nice .. 16.16.27 Quit MethoS-- (Connection timed out) 16.17.31 # kugel: see system_init() : icache and dcache should be active 16.17.51 # and mmu inactive, but i think we don't need memory management? 16.18.06 Quit stoffel (Read error: 113 (No route to host)) 16.18.10 # funman: the mmu is inactive. And thus the dcache is inactive 16.19.27 # oh 16.19.43 # look at the arm922 technical manual for the cp15 registers 16.19.56 # see you 16.19.57 # I did 16.20.18 Quit funman ("http://www.mibbit.com ajax IRC Client") 16.27.12 Join stoffel [0] (n=sfr@p57B4F9BF.dip.t-dialin.net) 16.29.28 Join Rabbit^^ [0] (n=Rabbit^^@72-24-220-205.cpe.cableone.net) 16.30.16 # Does anyone know if Rockbox works on Sansa View? I am also running Windows Vista. 16.30.49 # Rockbox runs on the players listed on the frontpage. That list does not include the view 16.31.40 # There's even a "Status" link 16.32.20 # Does anyone know of ANY FREE software that would enable bookmarking of MP3 files on the View? 16.36.17 *** Saving seen data "./dancer.seen" 16.37.31 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 16.45.53 Quit webguest42 ("CGI:IRC") 16.47.50 Quit Seed ("cu, Andre") 16.48.21 Join MethoS-- [0] (n=lem@host-091-097-245-039.ewe-ip-backbone.de) 16.51.51 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 16.53.48 Quit MethoS-- (Read error: 60 (Operation timed out)) 16.55.51 # Rabbit^^: You can't just "enable bookmarking" on the View. You either need to ask Sandisk to implement it in their firmware, or hope that an interested/skilled View owner ports Rockbox (or another alternative firmware, but I'm not aware of any likely candidates apart from Rockbox) to run on the View. 16.57.06 # Thank you. 17.01.39 Quit stoffel ("leaving") 17.02.29 Join webguest42 [0] (n=5773d21c@gateway/web/cgi-irc/labb.contactor.se/x-65d86b6b5a276a32) 17.02.43 Join stoffel [0] (n=sfr@p57B4F9BF.dip.t-dialin.net) 17.03.01 Quit Thundercloud (Remote closed the connection) 17.04.07 Quit webguest42 (Client Quit) 17.07.50 Quit MethoS- (Read error: 110 (Connection timed out)) 17.11.38 # can anyone comment on why jaunty alpha5 wont see my c240 no error message just http://paste.ubuntu.com/124707/ rockbox usb or alpha5 problem? 17.11.41 # i've made a first test, with a "normal" bootloader. i can't duplicate the reset-loop problem, mine just hangs with the gigabeat boot logo, but no progress bar. dual-boot works. about to try the padded single-boot. 17.11.47 Join PaulJam [0] (n=Paule@p54BEFB80.dip.t-dialin.net) 17.12.50 Join gartral [0] (n=gareth@adsl-75-33-91-251.dsl.bcvloh.sbcglobal.net) 17.12.53 # robin0800: Have you tried to narrow it down yourself? i.e. try the OF in alpha5, and Rockbox in other operating systems? 17.13.01 Join PaulJam_ [0] (n=Paule@p54BEFB80.dip.t-dialin.net) 17.14.14 # hmm, after starting to use the linux rbutil to update my bootloaderm rb itself comes up as "r20098:20153M-090301" 17.14.42 # s// bootloaderm/bootloader, 17.15.23 # What do you mean? The bootloader shows that version number, or Rockbox itself does? If the latter, then that's nothing to do with the bootloader. 17.16.21 # linuxstb: the latter, and i should be more specific, after i gave rbutil root, to install the bootloader and update rockbox, sorry 17.18.16 # and so it has? 17.19.18 # * gevaerts doesn't really see any question here 17.19.29 # * BigBambi neither 17.19.39 # You updated Rockbox and Rockbox has been updated... 17.19.40 # how do i return it to a normal build? 17.19.51 # ? 17.19.55 # Install a normal build. 17.20.12 # What do you mean by "normal build"? 17.20.15 # but it says "M" at the end of the build string, wich looks like a combined build string! 17.20.31 # M means modofied 17.20.37 # i know that 17.20.46 # But for some reason "normal" builds sometimes have it too 17.20.49 # linuxstb: yes windows ok of ok on alpha5 all outher usb products ok in alpha5 just rockbox so far 17.21.08 # i also know i shouldn't see it at the end of a build string that was from a build installed with rbutil 17.21.26 # That's the first time you say that... 17.21.31 # see what I just said 17.21.55 # ok... so i'm panicking for nothing? 17.22.05 # gartral: So your question is "Why does one of the Rockbox builds on the build server have the version string r20098:20153M-090301" ? 17.22.38 Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 17.23.11 # yea, if you all see it too, if not, then it's "why the heck is my comp giving me a weird glitch, and should i worry about this?" 17.24.07 # How on earth could your computer cause it? 17.24.15 # * BigBambi decides to be more simple 17.24.21 # gartral: No, don't worry 17.24.38 # gartral: your computer can not have modified the version string in that fashion by accident. 17.25.40 # cause in the past, iv'e been knopwn too do stupid things to my computer that leave it in a half functioning state without reliseing it, and nearly crashed an entire NAS server once.... 17.26.08 # but it was my one fault, non the less 17.26.59 # back to point: theres no problem and i still have an "official build", right? 17.27.14 # What target is this? 17.27.18 # YES 17.27.46 # e250, the only one i own 17.27.53 # gartral: Did you select "current build" in rbutil? 17.27.58 Quit J-23 ("ZNC - http://znc.sourceforge.net") 17.28.00 # yes 17.28.04 # gartral: look at http://build.rockbox.org/. There's some anomaly today for e200... 17.28.06 # jhMikeS: the beast did something that looked very much like updating the flash after i ran the updater, with a couple of reboots that displayed a progress bar and a "don't reset the player" message that i've never seen before... but i must still not have the "bad" flash, because i can boot a perfectly normal single-boot nk.bin, once i stop mistakenly sending the bootloader.bin instead. 17.28.55 Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.6/2009011913]") 17.30.16 # * linuxstb wonders who runs debussy.pauken.co.uk 17.30.37 # GodEater manages it, iirc 17.31.23 # gartral: If I was you, I would install the latest daily build 17.31.57 # that is what i have installed, according rbutil 17.32.32 Quit PaulJam (Read error: 110 (Connection timed out)) 17.33.51 # Possibly, but not according to what you said here 17.34.40 # ok, lemme see here 17.35.37 # r20098:20153M-090301 no change after manual unzip... 17.36.33 # After manual unzip of *what*? 17.37.02 # the rockbox.zip of the current builds page 17.37.22 # * gevaerts gives up 17.37.26 # I'd *guess* it's related to http://build.rockbox.org/ showing r20098 for some targets, but I think we need Bagder to figure out what's going on 17.39.13 # We basically have no way of knowing what that build is. Could be any mix of r20098 and r20153 code 17.40.10 # well, it has stable USB... 17.40.21 # gartral: daily and current are two different words 17.40.38 # oh 17.40.58 # * gartral learns to read farther back than one page! 17.40.59 # Why do we even offer "daily" builds? To aid in binary searches? 17.41.35 Join J-23 [0] (n=zelazko@unix.net.pl) 17.41.44 # + if the current i broken (less important now there are releases) 17.42.17 # soap: just for cases like this where the current build is doubtful 17.42.27 # It is not like gartral's problem is an uncommon one. Considering "support" is only offered for the (most recent) current build or releases then that also removes use for "daily" builds. 17.42.40 # Then cache 2, 3, 4 "current" builds. 17.42.55 # Hmm. Is there a reason why credits.pl resides in apps/plugins/ ? 17.42.59 # instead of daily ones. 17.43.40 # amiconn: because the credits.rock plugin is a plugin 17.43.41 # '? 17.43.56 # All other build scripts reside in tools/ 17.44.18 # soap: They're usually called "archived" builds in most cases. 17.44.58 # They have been useful to give someone an easy way to roll back if a single or a couple SVN revisions are bad. 17.45.03 # lazy programmer? 17.45.25 # gartral: Please stop making random unhelpful suggestions 17.57.47 Join Sedgewick [0] (n=Sedgewic@net-93-145-225-250.t2.dsl.vodafone.it) 18.01.16 Part gartral 18.03.26 Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) 18.06.23 Quit PaulJam_ (".") 18.14.04 Join saratogahome [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-0d2787e98c7732b2) 18.14.34 # does rbutil install the latest bootloader from SVN, or an archieved stable one? 18.15.14 # Archived stable. 18.16.02 # Llorean: any idea how old it is? 18.16.48 # I suppose if someone get "Version: r20108-090226" printed from the bootloader, they've not used rbutil? 18.17.09 # That means they've updated to the test bootloaders on the tracker, I'd assume 18.17.12 Join gromit`` [0] (n=gromit@ALagny-154-1-75-50.w81-48.abo.wanadoo.fr) 18.17.49 Quit robin0800 (Remote closed the connection) 18.17.58 # does the test version of rbutil install that bootloader or only the tracker? 18.18.05 # Only the tracker 18.18.09 # You need to use target-specific tools 18.18.29 # Any last objection against the sorting patch? I'm committing in a few minutes 18.18.33 # RButil *should* download bootloaders from download.rockbox.org as far as I know, so that a new version of the Util isn't needed with new bootloaders. 18.18.49 # kugel: The version on the tracker? 18.19.30 # kugel: What are the strings displayed in the settings menu, and what are the strings saved to the .cfg ? 18.20.26 # linuxstb: "sort interpret number", "digit,numbers" in the cfg 18.21.01 # Llorean's most recent suggestion in the settings menu 18.21.42 # You couldn't just say what that was? 18.21.47 # * linuxstb goes-a-searching 18.22.12 # linuxstb: "Interpret numbers while sorting", with the options "As digits" and "As whole numbers" 18.23.08 # * gevaerts doesn't immediately see what those mean 18.23.12 Join ShyK [0] (i=Shy@80.74.125.61) 18.23.33 # gevaerts: it describes perfectly what it does 18.23.36 # gevaerts: It's better than "Recognize numbers while sorting" with the options "true" and "false" 18.24.03 # Shouldn't that be "whilst sorting" ? 18.24.12 # kugel: I agree, but I have to read it several times to see it 18.24.17 # gevaerts: If the algorithm works like the sample seems to suggest, it recognizes all series of digits as a "number" rather than as a string of digits, so it's pretty descriptive. 18.24.28 # A better name is always welcome, though. :) 18.24.35 # I know :) 18.24.40 # * gevaerts decides to keep out of this 18.24.59 # but we cannot agree on a name. Also, the manual will cover this 18.25.07 # kugel: whilst not while I think 18.25.14 # ok 18.25.22 # I've never even seen "whilst" used. 18.25.24 # * kugel thought while == whilst 18.25.27 # kugel: if you find more than two people who like a name, you're doing well and you should commit :) 18.25.34 # Llorean: I think it's another British thing... 18.25.48 # kugel: they mean the same thing, it is a grammar difference 18.26.45 # Llorean: It is used over here for sure, I don't know if the States has dropped it 18.27.14 # We could replace it with "during" so that it doesn't seem weird to either type of English speaker. 18.27.28 # Or "when" ? 18.27.32 # Or "when" yes. 18.27.35 # during looks really wrong to me 18.27.40 # or when 18.27.43 # hehe, damn lag 18.27.51 # I prefer when to during 18.27.54 # I do too 18.28.06 # * gevaerts jouns in the when-admiration 18.28.11 # *joins 18.28.16 # OK, when 18.29.03 # so, during or when or whilst? 18.29.05 # * linuxstb can't remember a setting name ever having so much effort spent on it before... 18.29.10 # kugel: when 18.29.12 # * kugel neither 18.29.18 # kugel: when oir whilst 18.29.40 # to anyone developing or considering support for Musepack SV8: the format is finalized. we'll release it officially on the site today. changeset 435 is final/stable. http://trac.musepack.net/trac/ 18.30.10 # * rasher prods preglow 18.30.10 Quit Darksair ("Use the Force, Luke!") 18.30.25 # gevaerts: not a helpful answer (/me picked when now) 18.30.38 # ShyK: we'd like SV8 support, but I think the person to talk to is Buschel 18.30.54 # saratogahome: then Shy and I will talk to him 18.31.27 # saratogahome: seen him on this channel lately? 18.31.32 Join PaulJam [0] (n=PaulJam_@p54BEBC79.dip.t-dialin.net) 18.32.04 # Seed: i've seen him around lately, but he tends to pop in and out 18.32.15 # how big are the SV8 changes verses SV7? 18.32.36 # pretty huge 18.32.50 # in a good way 18.32.57 # in terms of code, it's not a big deal to adapt.. it's documented very well.. in terms of stability/resilience, a lot 18.32.57 # is there a reference fixed point decoder? 18.33.07 Quit Rabbit^^ (Read error: 110 (Connection timed out)) 18.33.30 # saratogahome: yes. can be compiled in fixed-point mode. 18.34.39 # Do you have any ideas about the optimisations that have been done for Rockbox? (asm for coldfire and arm) 18.35.05 # Buschmann is the only one who knows them in depth, i think 18.35.46 # psymodel-wise, encoding-wise, there is no difference, so there should be no problem 18.35.58 # the changes are mainly stream related 18.36.08 # we mostly only care about the decoder here 18.36.14 # encoding/decoding, that is 18.36.21 *** Saving seen data "./dancer.seen" 18.36.22 # so what matters is if you've changed the bitstream or the inverse filterbanks 18.36.23 Quit gromit` (Read error: 110 (Connection timed out)) 18.36.55 # the bitstream is changed, filterbanks are not 18.39.40 # "Warning: DWIDTH spec > max FONTBOUNDINGBOX" 18.41.47 # did anyone offer to send fuman a Sansa? 18.42.40 # I find it likely that the fund could fund one 18.42.46 # If no one else does 18.42.50 Join fml [0] (n=4fd3cbe8@gateway/web/cgi-irc/labb.contactor.se/x-6048a24b93155ed1) 18.43.10 # I was just going to offer to send him my Fuze 18.43.39 # i've still got a clip anyway 18.43.47 # I think we/he should ask Zagor, I think he doesn't really use it or hack on it 18.44.15 # saratogahome: is your fuze still functional? 18.44.18 # kugel: that warning is also a remnant of not quite clean implementation of convbdf. But it's harmless. 18.47.12 # kugel: yeah it works 18.47.32 # but i've been pretty useless anyway, so funman might as well have it 18.47.40 # and i've still got the clip 18.48.27 # saratogahome: What capacity is it? 18.48.47 # * linuxstb reads the email... 18.49.10 # * kugel bets his commit message will be controversial too 18.49.24 # kugel: Then change it... 18.51.06 # linuxstb: only a 2GB, so probably no good for funman 18.51.19 # hopefully someone will step up wtih a 4GB one for him though 18.51.23 Quit Xerion (Read error: 104 (Connection reset by peer)) 18.51.32 # honestly if the guy has free time, we should send him as many AMS players as he'll take 18.51.58 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 18.52.10 # saratogahome: I tought you experienced the >2GB problem too? 18.52.19 # saratogahome: I was talking about the Fuze (I know that wasn't clear). 18.52.30 Join webguest07 [0] (n=4b05639a@gateway/web/cgi-irc/labb.contactor.se/x-129239a4cc23ff8e) 18.52.35 # ah yeah, its an 8GB 18.52.48 Quit {phoenix} (Remote closed the connection) 18.52.51 # ah yea, now the email comes in 18.52.55 # and it definately has the flash problem, so it should be fine for that purpose, though i think funman was most interested in teh clip 18.53.00 # Could fs#9709 please be closed? I like the Keven's translations much better than my own. 18.53.27 Join z35 [0] (n=z35@h200.80.91.75.dynamic.ip.windstream.net) 18.53.37 Join toffe82 [0] (n=chatzill@adsl-75-12-169-240.dsl.frs2ca.sbcglobal.net) 18.55.16 # webguest07: You're Harry Tu/bookshare/countrymonkey ? 18.58.09 # yes. 18.58.34 # and? 18.59.23 # webguest07: well, if someone says "His translations are better than mine", it's helpful to know *who* says it... 18.59.25 # Having one identity is helpful, especially if you're asking for one of your patches to be closed. 19.00.35 # yes, I did the translations. 19.00.52 # It'd also help if his stuff was committed, but... 19.01.13 # alright, I'll go as bookshare from now on. 19.03.52 # what is the make target to build the fonts? 19.10.00 # fml: I'm not sure if there is - maybe it's part of buildzip.pl 19.10.37 # linuxstb: I'll search for convbdf in make files 19.11.23 # linuxstb: Is there "make fontzip"? 19.11.24 # fml: I've just checked - convbdf is called from buildzip.pl 19.11.33 # I can't remember if that exists or if it's just something someone suggested once. 19.11.34 # i.e. not directly by any Makefile 19.11.37 # * kugel is happy now 19.11.46 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 19.12.08 # yeah, fontzip exists 19.13.24 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 19.17.05 # linuxstb: ah, thanks! Is it called after the main build process (make) has been run? I.e. there is no chance for the font warnings to be displayed in the build table, right (even if they wouldn't be ignored)? 19.19.09 # It will be called as part of "make fullzip" - I expect the build table builds are just a "make zip". 19.19.25 # Although some fonts are made then... 19.19.37 Join Thundercloud [0] (n=thunderc@82.132.136.185) 19.20.58 # would anyone volunteer for the manual work of the sorting patch? 19.21.03 # There are other things it would be useful to build automatically as well - things like tools/database/ and checkwps. 19.21.38 # linuxstb: ok. I think I should talk to someone who anderstands the process of creation of the build table. Do we want to see the font warnings in there? 19.21.47 # kugel: Generally you should try to do the manual work before you commit, so they can go in together. 19.22.28 # Hm, I prefer the manual work in a seperate commit, that's how I did it before too. Is there a guideline about this? 19.22.47 Join midgey [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net) 19.22.55 # fml: I think the problem is that making the builds do a "make fullzip" would slow down the build process (larger zips to copy back to the server). But what can cause font warnings? 19.23.11 # kugel: "together" doesn't mean same commit, you could do the manual work and commit it immediately before or afte.r 19.23.13 # i.e. is it only when a bad font is committed? Or can other things accidentally break them? 19.23.20 # I mean, I'd gladly do it myself. But a) I don't have the manual toolchain, b) I'm not a native English speaker 19.23.49 # kugel: The idea though is not to have features sitting around waiting for someone to document them, because it generally means the manual just gets less and less correct. 19.24.41 # For example, if you're worried about your English you could post the text of the proposed manual entry to -dev so people can comment on it and help tidy it up. 19.24.49 # I know the idea. But I always have the manual and don't wait for someone 19.24.52 # linuxstb: warning can be caused by wrong font metrics or by the way Rockbox handles them (see my last comment in FS#9931) -- we have some such fonts in SVN 19.25.09 # kugel: I don't understand that sentence. What do you mean? 19.25.21 # I just ask if someone volunteers. If nobody does, I'll do it right now 19.25.35 Quit webguest07 ("CGI:IRC (EOF)") 19.25.38 Join bookshare [0] (n=4b05639a@gateway/web/cgi-irc/labb.contactor.se/x-c944c305a1ae6112) 19.26.11 # BigBambi maybe? :) 19.26.12 # fml: But the only thing that can add a new warning (or error) is a change to convbdf.c or one of the font files? 19.26.13 Quit bookshare (Client Quit) 19.26.28 Join booksharewebgues [0] (n=4b05639a@gateway/web/cgi-irc/labb.contactor.se/x-7a8e1b53ff88c4a2) 19.26.34 # linuxstb: I think yes. 19.26.39 # kugel: I was just suggesting that next time you wait another day or another few hours to write the manual patch as well. That way if *you* get busy and have to stop writing it, it doesn't mean we have a new feature sitting in SVN without a manual description. 19.27.08 Join bookshare [0] (n=4b05639a@gateway/web/cgi-irc/labb.contactor.se/x-1c312aa7dc9a4669) 19.27.09 Quit bookshare (Client Quit) 19.27.09 Quit booksharewebgues (Client Quit) 19.27.14 # fml: Then I don't think we need automated checking - a single test build (as we don't have target-specific fonts) is enough for a committer to confirm it's OK. 19.27.21 Join webguest07 [0] (n=4b05639a@gateway/web/cgi-irc/labb.contactor.se/x-6bd21c28ed03786f) 19.28.11 # linuxstb: and a change to convbdf can be caused by a change in Rockbox's core (convbdf should be honest and accurately tell what problems might occur with valid fonts if they are used in RB) :-) It's a chain reaction. 19.28.21 # fml: It sounds more like something for a separate webpage (possibly automated - like rasher's .lang file pages) listing current fonts with problems that need fixing. 19.28.38 # oh, I have the toolchain 19.28.40 # fml: How can a change in Rockbox's core change convbdf? Does it share code? 19.28.49 # linuxstb: yes, that's reasonable 19.29.32 # Maybe rasher could even be tempted to do it - it would fit into his site... 19.29.37 # linuxstb: suppose we'd extended the capability of RB's rendering engine. Then some warnings should disappear. 19.29.56 # linuxstb: I might. I expect this doesn't need to be updated terribly often? 19.30.00 # fml: Yes, but that would be a human making a change to convbdf.c? 19.30.11 Join bookshare [0] (n=4b05639a@gateway/web/cgi-irc/labb.contactor.se/x-cd58e40bd2a5a19c) 19.30.23 # linuxstb: yes, of course. Sorry, I wasn't clear enough 19.30.30 # rasher: A daily cronjob would seem sufficient. 19.30.58 # rasher: BTW, cyrillic glyphs are now a part of 12-Adobe-Helvetica 19.31.18 # fml: I'll see about updating the fontstats page. I don't quite remember what that involves... 19.31.59 # rasher: me too (I've never known it :-) 19.32.44 # Looks like I've got it automated.. hang on 19.32.49 Quit midgey () 19.32.49 Quit webguest07 ("CGI:IRC (Ping timeout)") 19.34.40 # kugel: I find the symbol names a bit misleading (I'd insert "NUM" in the middle) 19.35.39 Quit bookshare ("CGI:IRC (Ping timeout)") 19.35.48 # rasher, linuxstb: would you agree with clipping glyphs that can't be rendered by RB? 19.36.33 # * rasher doesn't know much about font rendering, but it sounds better than not including it at all 19.38.22 Quit PaulJam (".") 19.39.10 # * rasher uploads pngs and other stuff 19.39.26 # fml: I haven't been following the discussion. What does Rockbox do at the moment with such glyphs? 19.39.43 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 19.40.31 Quit Thundercloud (Remote closed the connection) 19.40.39 # linuxstb: the way rockbox handles them hasn't changed at all. Just convbdf generates "bad" glyphs (with some seemingly random bits at the edges) -- see screenshots in FS#9931 19.41.11 Join Thundercloud [0] (n=thunderc@82.132.136.185) 19.41.49 # linuxstb: and convbdf generates them like this because RB couldn't handle them in the correct way (i.e. how they are supposed to be handled by full size rendering engines) 19.42.25 Quit Thundercloud (Remote closed the connection) 19.42.31 # fml: OK, so the problem is that some fonts have glyphs designed to be taller than the "font height" ? 19.43.16 # linuxstb: yes 19.43.20 Quit nuonguy ("This computer has gone to sleep") 19.44.21 # Is this common? Sounds odd to me.. 19.44.39 # i.e. it will overwrite text above or below it... 19.44.48 # s/will/can/ 19.44.50 # linuxstb: it happens (as it seems to me) with some accented glyphs 19.45.17 Join DC1 [0] (n=dc1@pool-70-107-136-192.ny325.east.verizon.net) 19.45.32 # linuxstb: yes, that would happen. But RB can't do this hence the best option we have is to clip 19.45.49 # Is this valid? 19.46.17 # rasher: another option would be to reject such fonts 19.46.40 # I think clipping is fine, just curious 19.46.41 # I.e. convbdf would issue an error message and quit 19.46.49 # rasher: According to what I've read FONT_ASCENT is just intended for spacing, and glyphs are allowed to extend beyond it. 19.47.04 # fml: Do you know how many svn fonts that would reject? 19.47.19 # Llorean: yes, that's how I understand it now 19.47.25 Quit Chex (Read error: 104 (Connection reset by peer)) 19.47.50 # That doesn't seem useful for Rockbox - where we display lines with no line-spacing. 19.48.22 # linuxstb: not exactly. But > 1 :-) Some might be easy to correct (I've done this) because it's just a copy-paste error for one or two glyphs. But in others it's systematic 19.48.38 # is this good? 19.48.40 # http://pastie.org/403915 19.49.00 # It just seems to be saying "most glyphs are this height, but some are bigger", whereas we need to know the height of the biggest. 19.49.04 # kugel: I'd avoid the word "intuitive" as it means different things for different people 19.49.40 # "at the beginning or within filenames" => "in filenames" 19.50.10 # enables a sorting algorithm which is able to interpret series of digits at the beginning or within filenames as whole numbers and allows the files to be sorted based on their value rather than comparing one digit at a time. \setting{As digit} disables this algorithm, so that each digit is compared seperately. 19.50.11 # kugel: I'd also avoid the word "algorithm" 19.50.19 # kugel: I would refer to this being the default way Windows Explorer and OS X Finder sort things, and provide some examples. 19.50.32 # i.e. choose 3 or 4 names, and show them sorted in the two ways. 19.50.37 # And Nautilus! 19.51.38 # linuxstb: the settings (ascent, descent) define (a) the distance between two base lines and (b) how glyphs should be placed on a line 19.52.09 # rasher: well, nautilus has some more extras w.r.t to sortin 19.52.44 # fml: Maybe we're simply calculating "font_height" wrongly? i.e. using the distance between two base lines, whereas we should be using "distance between top of highest glyph and bottom of lowest glyph". 19.52.44 # kugel: Like what? It does use natsort. 19.53.12 # linuxstb: That might be smarter, given Rockbox' font renderer 19.53.33 # linuxstb: FONT_ASCENT and FONT_DESCENT are supposedly intended to be used for spacing, but we may want to use a calculated absolute height instead so that we can show and scroll full accent marks. 19.53.39 # rasher: ignores leading dots and underscores, _ and - within filenames sort the same 19.53.55 # linuxstb: I think we're not using it "wrongly" so much as "our case doesn't work well with their intended purpose" 19.54.04 # linuxstb: no, I think we do it correct. Doing it your way would avoid the need to clip but it would also change the distance between base lines and thus would change the "font picture" -- something explicitly set by the font designer 19.54.12 # kugel: Right, well as long as you avoid those things in your example, you *could* mention it, though there's probably no need to 19.54.20 # I meant "wrongly" in terms of "not the best way for Rockbox". 19.55.09 # fml: I don't understand. All we're doing is in effect setting a larger line-spacing between lines of fonts. 19.55.21 # s/we're/we would/ 19.55.35 # Bah, I meant "All we would be doing..." 19.55.38 # And that would *only* be for fonts which have glyphs that are "too large" 19.55.56 # linuxstb: you're right. But this "only" is considered a very important measure in a font 19.57.22 # Well, I can see five choices: 1) Reject the font; 2) Reject the glyph; 3) Clip the glyph; 4) Increase the font height; 5) Rewrite the Rockbox font rendering and scrolling code... 19.57.25 Join Thundercloud [0] (n=thunderc@82.132.136.191) 19.57.43 Quit saratogahome ("CGI:IRC (EOF)") 19.57.54 # linuxstb: With the demonstrated screenshots, the fonts are about 1.5 times as tall in some cases, that's a lot less lines per screen. 19.58.14 # Clipping *may* be better, I don't know how many fonts have problems, and how unreadable it will make them though 19.59.21 # Wow, that's a pretty poor font design if you have glyphs that high 19.59.34 # rasher: They go downward more than normal too, I think 19.59.49 # rasher: or a quite smart rendering engine :-) 20.01.07 # fml: How would that ever work without producing overlapping glyphs? 20.01.15 # I guess that adding clipping with a warning would be a sensible first step though, but it's not really a permanent solution. 20.01.31 Quit Thundercloud (Remote closed the connection) 20.02.05 # rasher: font design is not very simple. It's often a trade off. They "grey picture" is one of most important things (how you see a page from 3m distance) 20.02.36 # they -> the 20.02.57 # I don't see how you can claim you've made a good font if the user will have to fight with overlapping text 20.03.13 # And it's directly influences by the font height (ascend+descend) 20.04.15 # rasher: that glyphs occur not very often (I think). And if they do occur often (in a certain language) then the font design should be changed for using in that country 20.04.26 Join midgey [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net) 20.04.49 Join Thundercloud [0] (n=thunderc@82.132.136.182) 20.05.43 # Well, is there a "standard" line spacing? 20.05.54 # I mean, I know most print isn't spaced like Rockbox is 20.05.57 # linuxstb: I think the options 2 and 5 are not feasible 20.06.04 Join Actium [0] (n=none@ool-44c0abd0.dyn.optonline.net) 20.06.38 Join IuDeX [0] (n=52a0f8f7@gateway/web/cgi-irc/labb.contactor.se/x-710fa85d83c53f53) 20.06.42 # linuxstb: and if we had these error/warning messages thise fonts wouldn't be accepted in SVN 20.07.39 # it's good to see that -> funman is back ;] 20.08.13 # Llorean: no, I think there's no such thing. There might be some guiding rules, e.g. "line spacing should be ~2* x-height". But in the end it's a matter of design 20.08.14 Quit IuDeX (Client Quit) 20.09.59 # IMP the linuxstb's options 1 and 3 (reject or clip the font) are the best 20.10.07 # Apparently one pattern is to make each line 1.2 times the point size of the font on that line. 20.10.28 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-3c50109b8d4205b1) 20.10.31 # We could do that *and* clip. This would introduce a little more spacing, so the clipped images could be more visible on average. 20.10.46 # We'd have to clip less off of them, when/if we do 20.11.21 # Llorean: font height *is* the line height. I.e. it includes vertical space 20.12.24 Join fgallina [0] (n=user@200-122-75-110.cab.prima.net.ar) 20.12.39 # fml: What about the leading many/most things have? 20.13.31 # Llorean: sorry, I don't understand. What is leading? 20.14.01 # fml: http://en.wikipedia.org/wiki/Leading 20.15.26 # Ah, ok. But that's only done in word processing and DTP systems. Rockbox always uses leading = 0 (i.e. no extra space between lines) 20.16.19 # It's also done in display of webpages through CSS properties, etc. 20.16.42 # Basically, anywhere you're going to display multiple lines of text you need to decide if you're going to be spacing them. Apparently some fonts assume a certain minimum added line spacing (for some reason). 20.17.41 # Is there a way to compile my test plugin and test it on the uiSimulator? 20.18.05 # fgallina: Yes, by compiling a simulator build with your plugin included. 20.18.06 # Llorean: No, I think that those are extra features. A "natural" picture, i.e. as thought by the font designer, is without leading 20.18.45 # fml: I find this hard to believe since leading has been around as long enough that the term actually refers to the lead spacers used in old print typography. 20.18.56 # By now people ought to know that their lines will include spacing. 20.19.59 # Llorean: if I make any changes to my plugin how can I recompile only my plugin? 20.20.30 # fgallina: If you compile in the same build directory it should only recompile files that need recompiling. 20.20.36 # Llorean: leading has always been used to fill up pages and paragraphs. This is similar to how char spacing is changed to fill the lines in newspapers. But that's advanced typesetting which we don't have in RB 20.21.41 # But why *shouldn't* we simply space lines to make it more readable? 20.23.59 # Llorean: we could (of course at compile time, i.e. when running convbdf). But that wouldn't solve all problems because something would always be left. But yes, we could introduce a "stretchability" or "tolerance" parameter to convbdf. 20.24.56 # My suggestion is to add a little extra spacing when necessary, but temper it with a maximum after which we clip so that we don't end up having giant amounts of spacing for a few characters that the user may never even see. 20.27.02 # I still think that making Rockbox consider "font height" as the maximum distance between the top of the highest font and the bottom of the lowest is more useful - fonts which take advantage of that feature don't seem suited to Rockbox. 20.28.10 Join petur [50] (n=petur@rockbox/developer/petur) 20.29.13 # linuxstb: if we had the warnings the font wouldn't have been included (because it's apparently not suited for RB) 20.30.21 # linuxstb: I mean, the person who wanted to include it would see the warnings and wouldn't do it in the end 20.30.29 # I just meant that if a warning was added, we would know what fonts it affected, and could then decide what to do with them - one option would be to delete the font. 20.31.43 Join Chris_Black [0] (n=Sedgewic@net-93-145-246-150.t2.dsl.vodafone.it) 20.34.07 # linuxstb: the patch in FS#9931 adds the warning and clips. We can then decide what to do. 20.36.25 *** Saving seen data "./dancer.seen" 20.38.32 Quit stoffel ("leaving") 20.43.02 Quit fgallina (Remote closed the connection) 20.45.48 Quit midijunkie ("?(???~•~)?") 20.46.30 # petur: Mind testing some bootloaders? The current is broken, and we don't know when it stopped working. Last positively known good is r12000-something 20.47.13 # let me fetch it first and see if it still holds some charge 20.47.17 # rasher: Maybe it would be more useful to build ipodpatcher and sansapatcher binaries. Windows/Linux binaries are easy - just copy the bootloaders into the sansapatcher/ipodpatcher directory and type "make" or "make ipodpatcher.exe" (and same for sansapatcher) 20.48.08 # How does the H10 bootloader installation work? 20.48.16 # Although I think you may need to uncomment two lines in the Makefile for ipodpatcher.... 20.48.25 # * linuxstb has no idea 20.48.30 # I don't think we need testing for anything but H10 (and mrobe100) at this stage 20.48.54 # Ah, OK. I thought you were talking about rebuilding all the PP bootloaders. 20.49.02 Quit Sedgewick (Connection timed out) 20.49.23 # linuxstb: Turns out only the sansas have changed behavior, and those have been pretty thoroughly tested already 20.49.39 # The ipods never did any usb detection in the bootloader. I didn't know that 20.49.48 # I remember having quite a bit of trouble taming my H10 when I got it first... 20.50.41 # petur: A selection of bootloaders (both ums and mtp) at http://rasher.dk/rockbox/h10_5gb/ 20.51.00 # heh 20.51.13 # it is currently charging a bit... 20.51.56 Quit midgey () 20.59.41 Quit fred_2 (Remote closed the connection) 21.01.14 Join robin0800_ [0] (n=quassel@general-ld-216.t-mobile.co.uk) 21.02.08 Join fred_2 [0] (i=fred@hpc-cluster.hamburgnet.de) 21.04.57 Join dberg918 [0] (n=dave@cpe-098-121-161-003.ec.res.rr.com) 21.05.50 # hey, just wanted to put something on the IRC record 21.06.14 # I was here a few days ago talking about FLAC files that were skipping on my H10 20GB 21.06.30 # turns out the problem was the album art in those directories 21.06.49 # Ah, so nothing to do with them being FLAC files? 21.06.54 # ever since resizing was committed to SVN, I stopped manually resizing everything 21.06.59 # nope 21.07.17 # so the art in those directories was pretty big 21.07.23 # that's what was causing problems 21.07.28 Join jaykay [0] (n=chatzill@p579E76E9.dip.t-dialin.net) 21.07.28 # Ah, so the problem is the delay when resizing your album-art? 21.07.32 # yeah 21.07.57 # That sounds nasty... 21.08.03 # in one directory, it was bigger than 1000x1000, so the .bmp was like 5MB 21.08.41 Nick linuxstb is now known as beer (n=linuxstb@rockbox/developer/linuxstb) 21.08.42 # I'm not experiencing lag with art as large as 500x500 21.08.56 Nick beer is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) 21.09.11 # which come out to be about 732.5kb 21.09.14 # comes* 21.09.14 Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) 21.09.35 # What device is this on? 21.09.39 # still hefty compared to 60kb jpgs 21.09.51 # this was on an H10 20GB 21.10.02 # I know, what am I doing with 500x500 album art 21.10.25 # dberg918: that wouldn't really help any, since the delay happens when resizing, and a 60kb jpg would uncompress to a large size before resizing (unless we cheat) 21.10.28 # 500x500 seems to be normal for album-art I've downloaded 21.10.45 Quit Thundercloud (Remote closed the connection) 21.10.48 # rasher: It could also be the time taken to read 5MB from disk... 21.10.58 # Or at least, that doesn't help... 21.11.13 # True. Hard to know which it is, I guess 21.11.24 # that's what I figured linuxstb, especially if you're trying to load FLAC files into the buffer all the while 21.12.31 # so yeah, if anyone comes in talking about lagging playback, checking album art is certainly worth a mention 21.12.34 Quit Chris_Black ("off") 21.13.10 # No-one has tested a H10 20GB it seems, but according to this page http://www.rockbox.org/twiki/bin/view/Main/DiskSpeed the similar ipod 4G reads at either 2215 KB/s or 3495 KB/s, depending on whether the read is aligned. 21.13.20 # should not reproducable bugs be closed in the tracker? 21.13.36 # So reading that file could take a couple of secons. 21.13.47 # jaykay: There's no simple answer to that 21.14.03 # * linuxstb wonders what thread does the album-art reading and resizing 21.14.29 # rasher: http://www.rockbox.org/tracker/task/9436, the player froze while normal playback, he didnt manage to reproduce it 21.15.04 Quit robin0800_ ("No Ping reply in 30 seconds.") 21.15.28 # how did I not find this DiskSpeed page in my searches on rockbox.org? 21.15.35 Join robin0800 [0] (n=quassel@general-ld-216.t-mobile.co.uk) 21.15.53 # it answers pretty much all the questions I had... 21.15.57 # dberg918: But I think I would call that a bug - if we say to users that they can use any size album-art, I wouldn't expect large images to interfere with playback. 21.16.35 # shall I file a report about revising some documentation? 21.17.04 # Was it jhMikeS who committed a change that might fix all sorts of lock-ups on h1x0? 21.18.42 Join gregorovius [0] (n=diego@190.55.80.21) 21.19.13 # ah yes, r19991 21.20.17 # linuxstb: the AlbumArt page makes no mention of using any size album art...but it doesn't make a recommendation either 21.20.53 # rasher: there are rather excellent cheats available when decoding jpeg - you can use a partial iDCT that actually uses fewer operations than decoding all of the coefficients, to produce a smaller block. this can be done for any N/8 scale if chroma is not subsampled, and i think any N/4 scale if it is. 21.21.07 # Unhelpful: Yeah, I just realised that while I was typing it 21.21.31 Quit fml ("CGI:IRC 0.5.9 (2006/06/06)") 21.21.42 # maybe if there was just a disclaimer stating that album art size can adversely affect initial playback? 21.22.05 # dberg918: I'll add one to the manual 21.22.06 # dberg918: did it? it shouldn't, the scaler yields every row. 21.22.09 # dberg918: I would say it's a bug in Rockbox, not a bug in the documentation. Although that's debatable - if it's hard to fix, we would need to tell users to limit their art to a certain size. 21.22.26 # oh 21.22.49 # perhaps the actually buffering code doesn't yeild enough while loading the bmp into memory? 21.22.52 # so, you're saying the album art should be loaded kind of, "around" playback? 21.23.14 # though I suppose this would go away if we got jpeg support in core . . . 21.23.20 # * rasher will hold off doing anything then 21.24.00 # That's how I would have expected it to work. Although with FLAC (and any similar high-bitrate codec) the problem would be that the decoding thread runs out of data before the album art is loaded, and the next track isn't buffered until after the metadata (including album-art) is loaded... 21.24.12 Quit BHSPitLappy (Remote closed the connection) 21.24.26 # s/would be/could be/ 21.24.35 # linuxstb: or at least recomment something. Like saying that having bmp's bigger than screen size doesn't make much sense (and may cause playback problems) 21.24.55 # saratoga: well, isn't the bitmap loaded *by* the buffering thread? the yield should suffice to prevent stalling of playback of buffered material, but obviously nothing can be done about getting the next track into buffer, unless bitmap loads are split to another thread 21.25.04 # * rasher thought the album art thread scaled while loading, so the yields should happen while reading a swell 21.25.20 # * rasher was wrong, it seems 21.25.34 # ...is there an album art thread? 21.25.54 # i assumed it was done by buffering, in which case Unhelpful's explination makes sense 21.25.54 # I don't think so 21.26.02 # I'm guessing it's done on the buffering thread as well. 21.26.10 # the loading happens in the buffering thread, iiuc 21.26.17 # does the ATA DMA patch work on the H10? 21.26.37 # saratoga: i'm only guessing it is... but it would explain the behavior 21.26.38 # So either: a) the buffering/resize thread is starving the codec thread; or b) the codec thread runs out of data. 21.27.25 # the lag/skipping happens right at the beginning of playback 21.27.40 # Unhelpful: That's not quite what I meant to type :) 21.27.44 # You mean when you start the first track? 21.27.47 # I hear about 1 second of music, then it skips 21.28.05 # it happens whenever I play a track in a directory that has gigantic album art 21.28.18 # play as in, actively select 21.28.21 # could the bitmap be *so* large that yield-per-line doesn't suffice? 21.28.40 # i doubt it 21.28.47 # and anyway, the CPU should boost in that case 21.28.48 Join calman_ [0] (n=caleb@66.213.109.43) 21.28.51 # and I think the lag was longer the bigger the album art 21.29.02 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 21.29.12 # Isn't the CPU always boosted when buffering? 21.29.18 # * linuxstb is confused - he would have expected the first track's album art to be loaded before the track starts decoding. 21.29.20 # saratoga: resize_on_load boosts around the call to the actual scaler 21.29.26 # ah ok 21.29.30 # Though I seem to recall FLAC being able to easily allow PCM to underrun in the past due to bad VBR estimation (or something) 21.31.28 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 21.31.32 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-be259a1f092718b1) 21.32.31 # * linuxstb wonders if Nico_P can explain how AA works... 21.33.03 Quit SirFunk_ (Connection reset by peer) 21.33.33 # the ATA-DMA patch doesn't add support for the H10, but it probably could 21.33.42 # in which case the read speed would likely go up a lot 21.33.45 Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) 21.35.29 # rasher: the first H10 bootloader I tried (r11000) already fails to load rockbox (-1) - is this the issue I'm looking for? 21.36.43 # petur: It should load Rockbox but not the OF... :\ 21.37.00 # saratoga: Have people done test_disk.c benchmarks with that patch? Browsing FS#9708 quickly, I can't see any. 21.37.08 # petur: There's a report on the current bootloader in FS#9955 21.38.03 # petur: 11000 might be broken as well though, I guess 21.38.09 # Try 12k and 13k 21.38.10 # rasher: my bootloader dates from 2007/08/20, maybe something changed? 21.38.14 # I ĺl try 21.38.29 # I'm quite sure a lot of things changed! 21.38.49 # * linuxstb realises he should have actually searched for "test_disk" in FS#9708... 21.39.09 # Gevaerts USB tests w/ CF showed a 3x improvement in read speed at least 21.41.09 # its really strange that doesn't translate into a battery life improvement 21.42.24 # Does the disk spin down immediately after buffering? 21.42.33 # Well, how long does Rockbox spend reading from disk during a typical battery benchmark? 21.42.39 # Also, non-CF isn't nearly as dramatic 21.43.00 # petur: I think we're basically in a position where it would be great if we could create *any* bootloader that works :\ 21.45.40 Quit robin0800 ("No Ping reply in 30 seconds.") 21.45.42 # linuxstb: http://www.rockbox.org/tracker/task/9708#comment27592 21.47.03 Join robin0800 [0] (n=quassel@general-ld-216.t-mobile.co.uk) 21.50.04 Join einhirn [0] (n=Miranda@p4FC6066E.dip0.t-ipconnect.de) 21.50.11 Join rocko [0] (n=rocko@c-67-167-117-152.hsd1.il.comcast.net) 21.50.39 # rasher: r13000 boots rockbox 21.50.49 # petur: And the OF? 21.51.07 # petur: does r11000 fail to load rockbox because it is looking in the wrong place? As in the root of the drive (where y'all used to put it) vs the .rockbox folder? 21.51.08 # hmm how do you boot OF? 21.51.21 # soap has a point 21.51.24 # soap: first thing I tried ;) 21.51.30 # I thought that by the time we were on PP targets, we always looked in both. 21.51.43 # * gevaerts points to the helpful manual :) 21.52.16 # Llorean: You've long held that view, but IIRC we had quite a bit of problems with older bootloaders and the iPod series upon the switch. 21.53.09 # soap: The problem we had was that it looked in the root before in .rockbox, so it loaded the older build. 21.53.17 # Not that it didn't look in .rockbox at all. 21.53.29 # but it isn't petur's issue (him being (at least) one step ahead of me already). Ahh on the sequence. 21.53.58 # Yeah. I'm pretty sure the iPod bootloader always looked in both, but the default order was bad for the changeover. 21.54.03 # But, I could be wrong. 21.54.42 # ah... hold cancel while starting 21.54.54 # r13000 also boots OF 21.55.16 # petur: \o/ 21.55.30 # r7976 was when the iriver bootloader started looking in .rockbox, so that's far earlier 21.55.31 # wow.... I wonder what iriver did to make that touch strip work soo well in their firmware 21.56.39 # petur: Okay, so the binary search is on 21.57.16 # petur: Prod me if you want me to build some more bootloaders 21.57.34 Quit robin0800 ("No Ping reply in 30 seconds.") 21.58.10 Join robin0800 [0] (n=quassel@general-ld-216.t-mobile.co.uk) 22.06.03 Quit gregorovius () 22.07.40 Quit jaykay ("ChatZilla 0.9.84 [Firefox 3.0.6/2009011913]") 22.07.54 Join Thundercloud [0] (n=thunderc@82.132.136.182) 22.13.49 # rasher: 14k is ok, 14.5k only boots RB 22.14.03 # petur: progress! 22.14.22 Quit calman_ () 22.14.37 # Compiling some bootloaders in that range now 22.15.14 # * petur hums 'bakerman is baking bread' while walking to the oven 22.16.00 Join calman_ [0] (n=caleb@66.213.109.43) 22.16.55 # petur: Uploaded in the same location 22.17.01 # I want to fix the vorbis comment crash bug 22.17.08 # but i have a question 22.17.21 # is it ok if I apply a max size limit on vorbis tags? 22.17.34 # We already have one for ID3, so I don't see why not 22.17.40 # because right now I can fix the bug on the tracker just by checking the return value of malloc 22.18.09 # but if someone puts a large tag thats smaller then the codec buffer it will pass the malloc, but still crash later on because there won't be enough memory left for decoding 22.18.35 # rasher: do you know what a sensible limit is? 22.18.49 # No idea about that, no 22.19.06 # I was thinking 10KB might be a reasonable limit for a tag 22.19.23 # since I doubt rockbox can productively display vorbis comments even 1/10th that size 22.21.41 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 22.22.00 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-fbb25d6c26dc66ba) 22.23.46 Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-28145115cfcecac5) 22.24.43 Quit Neovanglist (Read error: 113 (No route to host)) 22.24.46 Join Neovanglist [0] (i=Neovangl@69.31.129.33) 22.29.28 Nick Horschti is now known as Horscht (n=Horscht@xbmc/user/horscht) 22.30.07 Join redbindelta [0] (n=50bb6921@gateway/web/cgi-irc/labb.contactor.se/x-8a5fcd55a903210e) 22.34.43 # ok 10000 characters it is 22.34.49 Quit redbindelta (Client Quit) 22.35.27 Join fgallina [0] (n=user@200-122-75-110.cab.prima.net.ar) 22.35.33 # That's not 10KB 22.35.39 # i know 22.35.48 # Alright 22.36.02 # I've written a plugin, I compiled it but it is not listed on the available plugins in my uiSimulator 22.36.04 Join Red_Build_Delta [0] (n=50bb6921@gateway/web/cgi-irc/labb.contactor.se/x-5aafd2966a729d45) 22.36.19 # why could this be caused, I'm executing make fullinstall after make 22.36.27 *** Saving seen data "./dancer.seen" 22.36.34 # fgallina: How did you compile it? Did you add it to apps/plugins/SOURCES and apps/plugins/CATEGORIES? 22.36.37 # rasher: between 14000 and 14050 22.36.45 # in SOURCES 22.37.00 # petur: Building those.. 22.37.24 Quit nuonguy ("This computer has gone to sleep") 22.37.33 # does the red in the lower build table influence the functionality of the current build ? 22.37.38 # fgallina: *and* 22.38.06 # Red_Build_Delta: no, the first row is the current build 22.38.35 # Red_Build_Delta: the lower table simply visualises size changes in Rockbox code 22.39.21 # oh, I thought he means the reds in the bottom row in the first build table 22.39.34 # thanks rasher! 22.39.46 Quit Xerion (" ") 22.40.04 # fgallina: This seems to be a common error - where did you check for what to do? 22.40.05 Quit Red_Build_Delta (Client Quit) 22.40.29 # petur: some more uploaded.. a few builds failed 22.41.03 # actually the page on the wiki related on how to write plugins was not helping very much 22.41.26 # it only recommended the vmware image which I don't want to use 22.42.27 Join Oniak [0] (n=IceChat7@CPE000f668dcdf2-CM001cea3ddcb4.cpe.net.cable.rogers.com) 22.42.54 # Is it possible to install rockbox on my creative zen portable media center? 22.43.12 # is there anything on the site to suggest you can? 22.43.26 # fgallina: It did actually tell you to add your plugin to the CATEGORIES file though 22.43.56 # Not really anything but I figured Id ask. 22.44.10 # Oniak: The site is up to date. 22.44.43 # Yes, and that means? 22.45.07 # Oniak: That if your player was supported, it would be in the list of supported players. 22.45.26 # You mean the thing under manual install 22.45.37 Join rehpotsirhc [0] (n=421a4112@gateway/web/cgi-irc/labb.contactor.se/x-406357f932ec2b20) 22.45.41 # he means the list on the front page 22.45.52 # OHhhhh 22.45.53 # k 22.47.22 Part Oniak 22.47.23 # * JdGordon assumes he missed the kill-kugel post commit party? :D 22.47.38 # JdGordon: No, I think there's still time. 22.47.47 # Did he break something, or something? 22.47.51 # saratoga: What "malloc" are you referring to (for vorbis comments) ? 22.48.02 # * amiconn grumbles about the delta for the unnatural sorting :\\ 22.48.13 Quit rehpotsirhc (Client Quit) 22.48.18 # Llorean: no... just the usual post commit rant about deltas and unwanted features :) 22.49.12 # There we go 22.49.45 # petur: Uploaded all bootloaders between r14000 and r14050 now 22.49.50 Quit DC1 ("$4e75") 22.50.05 # fine. I'm between 14000 and 14015 atm 22.50.11 # Eeek 22.50.16 # Those are the ones that don't compile 22.50.16 # * amiconn wonders what he missed 22.50.24 # (re bootloaders) 22.50.35 # rasher: yes you are right, sorry about that. However I think it should be remarked, perhaps making a title regarding compilation. 22.50.38 # H10 bootloaders failing to load the OF 22.50.43 # amiconn: Trying to track down when the h10_5gb bootloader stopped being able to boot the OF 22.50.49 # ah 22.50.59 # Well, my H10 is able to boot the OF 22.51.18 # I'm using the latest official bootloader iirc 22.51.20 # But you're probably using something like ~r12800 if you're using the release bootloader 22.51.23 # rasher: are you still uploading or what? 22.51.35 # petur: no, done.. the missing ones don't compile 22.51.45 # eeek indeed 22.51.50 # Between r14003 and r14016 22.52.01 # * linuxstb sees saratoga's commit and wonders why Tremor is reading tags at all... 22.52.24 # * amiconn recommends to compared .map file between the latest working and a non-working one 22.52.46 # r14004 looks likely to possibly break a bootloader 22.52.49 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 22.53.20 # The non-working bootloader usb in bootbox turned out to be the missing usb thread, which was visible in the .map 22.53.31 Quit Thundercloud (Remote closed the connection) 22.53.35 # I suppose the fix in r14015 broke something for booting the OF 22.53.52 Join DC1 [0] (n=dc1@pool-70-107-136-192.ny325.east.verizon.net) 22.54.00 # 14001 is ok, going for 14003 now 22.54.15 # r14006 *might* also be interesting, but less likely, I think 22.54.40 # saratoga: Wouldn't the correct fix for FS#9866 be to stop Tremor from reading tags? Lear mentioned that in the comments on that task. 22.55.48 # 14003 is fine as well 22.55.59 Part calman_ 22.56.20 # * rasher compiles and saves .map files 22.56.31 # is this good? http://pastie.org/404055 22.56.34 Quit ender` (" Please help Conserve Gravity - Play Chess, not Basketball.") 22.57.17 # kugel: looks good to me 22.57.33 # Though I'd probably use something other than foo and bar 22.57.49 # Make it look slightly more plausible 22.59.06 # and what? :) 22.59.33 # I could pick some random album of mine 22.59.40 # kugel: I'd change the first sentance to something like "enables a sorting which resembles the sorting in most standard browsers, where groups of digits are considered numbers and sorted before letter, e.g ..." 23.00.14 # sorted before letter? 23.00.28 # kugel: Doesn't really matter, I just think using foo bar etc looks a bit "unpolished" 23.01.00 # kugel: letters* 23.01.19 # JdGordon: That doesn't really explain what it does 23.01.20 # yea, but that's not true 23.01.51 # * kugel picks johnny cash 23.02.39 Join ender` [0] (i=krneki@foo.eternallybored.org) 23.03.05 # kugel: maybe just s/, for example,// ? 23.03.42 # kugel: Maybe add "episode 1 / episode 10 / episode 2" to the list? 23.04.04 # fine 23.04.08 # kadoban: Why? 23.04.33 # kugel: To make obvious that it's not only about initial numbers 23.04.38 # kugel: it looks overly complicated and seems to work without it? maybe it's just me 23.04.54 # petur: so 14003 is good, 14016 is bad, and the ones in between don't build? 23.05.07 # petur: Wait, how about 14015? 23.05.16 # 14015 is also bad 23.05.28 # I never tried 14016 23.06.14 # * kugel adds episode and a \caption 23.06.32 # Ah, right, no point 23.06.48 # * rasher attempts to collect .map files again 23.09.10 Quit fgallina (Remote closed the connection) 23.10.01 Join drehpotsirhc [0] (n=christop@cpe-066-026-065-018.nc.res.rr.com) 23.10.06 Quit einhirn (Read error: 104 (Connection reset by peer)) 23.10.21 Quit Zoxc () 23.10.49 # The obvious change between r14003 and r14015 is the removal of set_cpu_frequency, if I read this right 23.11.19 # http://rasher.dk/rockbox/h10_5gb/bootloader.map.r14003 - http://rasher.dk/rockbox/h10_5gb/bootloader.map.r14015 23.12.32 # hah 23.12.38 Quit drehpotsirhc ("Leaving") 23.12.55 # Iirc the H10 rom sets the frequency to 80MHz. I guess the OF expects that... 23.15.29 # That doesn't sound terribly unlikely 23.15.54 Join robin0800_ [0] (n=quassel@general-kt-199.t-mobile.co.uk) 23.17.26 Quit kugel (Nick collision from services.) 23.17.31 Join kugel [0] (n=kugel@rockbox/developer/kugel) 23.22.14 Quit robin0800_ ("No Ping reply in 30 seconds.") 23.22.45 Join robin0800_ [0] (n=quassel@general-kt-199.t-mobile.co.uk) 23.22.55 # amiconn: Any idea how to fix? 23.25.43 Join lunix151 [0] (n=richmast@CPE001217414019-CM0011e6c78dbd.cpe.net.cable.rogers.com) 23.27.01 # Hello everybody 23.28.10 Quit tyfoo (Read error: 104 (Connection reset by peer)) 23.28.18 # I just started to test the new usb support in the Sansa e200 23.29.13 # I can mount it just fine but rhythmbox and banshee both hang and spit the following message "ptp_usb_getresp: detected short response of 32 bytes, expect problems!" 23.29.22 # * amiconn summons Zagor 23.30.00 # lunix151: Hmm, sounds like those apps are attempting to use MTP 23.30.07 # lunix151: That sounds a bit like they're expecting an MTP device 23.30.07 # * linuxstb summons gevaerts 23.30.10 # Too slow.. 23.30.19 # yes 23.30.23 # * gevaerts was going to say the same 23.30.41 # * Bagder thought PTP was for cameras... 23.30.48 Quit robin0800 (Read error: 113 (No route to host)) 23.30.49 # Bagder: MTP is a dialect of PTP 23.30.56 # Treating a mass storage device as MTP isn't going to work well 23.31.00 # ok so the rockbox firmware doesn't support mtp then? ill just turn off that plugin the 23.31.03 # then 23.31.05 # makes sense 23.31.19 # Bagder: And I believe those use libgphoto or a derived library to do mtp 23.31.24 # Maybe they're hard-coded to try MTP, since modern firmwares on the e200 have that auto-detect feature that does UMS if it thinks the host can't do MTP? 23.31.47 # Are the VID/PID different in MTP mode? 23.31.48 # libmtp is based on libgphoto I believe. At least, there are lots of ptp_* functions in there. 23.32.02 # Mystery solved. 23.32.08 # lunix151: exactly. I'd like to have mtp, but probably not enough to do the work myself... 23.34.09 Quit robin0800_ (Remote closed the connection) 23.34.10 # Llorean: Yes, according to http://www.rockbox.org/twiki/bin/view/Main/DeviceDetection 23.34.25 Quit nibbler (Remote closed the connection) 23.34.29 # I don't know what it gives in that magic mode though... 23.35.43 # I expect that this magic mode is just mtp with automatic disconnect and reconnect as msc if it doesn't get an mtp connection 23.45.57 # So the OF has "magic mode" and "UMS only mode" ? 23.46.28 # You can also chose mtp only 23.46.29 Quit DC1 (Read error: 104 (Connection reset by peer)) 23.46.29 # I think so, yes 23.46.46 # in which case it doesn't connect at all, if the host cannot do mtp 23.46.53 Join jeffronius [0] (n=jomegata@69.12.221.210) 23.47.11 Quit bertrik ("Leaving") 23.47.28 Quit bluebrother ("leaving") 23.48.15 # saratoga: had a look at my latest disable wps update patch? 23.48.50 Quit petur ("Zzzzz") 23.50.04 # amiconn: Do we even need new bootloaders for the H10 - ie. does it boot Rockbox on usb plugin? 23.51.04 Quit Llorean (Read error: 104 (Connection reset by peer)) 23.51.07 # gevaerts: Same question for the mrobe:100 - does the current bootloader need changing at all? 23.51.09 # rasher: the one report says it boots the of 23.51.14 # well I just disabled the mtp plugin in banshee then created a .is_audio_player file on my sansa and its working great now 23.51.34 # kugel: where? 23.51.50 # rasher: http://www.rockbox.org/tracker/task/9955#comment28566 23.52.00 # rasher: currently it goes straight to OF (ROM?) USB mode on startup if plugged in. Not sure if that's the rockbox bootloader or the OF 23.52.31 # Ah, missed that. Seems like some OF thing, but pre-rockbox? 23.52.43 # * rasher has little idea about the H10+ 23.52.53 # Possibly. I'm not entirely sure 23.53.41 # Anyway I think it's good to check that the code still works :) 23.54.04 # This is true 23.55.06 Join Llorean [0] (n=llorean@ppp-70-243-32-116.dsl.hstntx.swbell.net) 23.56.34 # * pixelma sees a weirdness in an H10 sim (the "small" one) - afte simulation turns off the backlight the first time and a button press there is a black rectangle at the bottom of the simulated screem 23.56.38 # screen too 23.56.51 # That seems to be an SDL bug 23.57.01 # kugel reported it for the e200 sim as well