--- Log for 22.06.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 19 days and 7 hours ago 00.00.07 Join BeChris [0] (i=5c89760a@gateway/web/freenode/x-10f8b5231d478a5e) 00.00.09 # New commit by 03zagor (r21461): Specify -s to perl. 00.00.17 Quit stripwax ("http://miranda-im.org") 00.00.21 # New commit by 03kugel (r21462): FS#10365 - Optional debug output for albumart.c ... 00.00.22 # heh, the upload didn't even print "time spent", it was too fast 00.00.24 Quit BeChris (Client Quit) 00.00.26 # busy commit bot :P 00.00.29 Quit notlistening (Remote closed the connection) 00.00.30 # oh that was the .log 00.00.33 # Blue_Dude: thanks for that! 00.00.43 # 3 seconds for the zip 00.00.53 # does it just build the current revision over and over? 00.00.56 # so the client will update itself as you push new versions to svn? 00.00.59 Join BeChris [0] (i=5c89760a@gateway/web/freenode/x-7ee6cc8b6c3ad698) 00.01.11 # Hello everybody 00.01.12 # Welcome! I was trying to debug another module and had to wade through all the chaff. They just had to go. 00.01.23 # (i'm not going to be running a build server, i'm just testing) 00.01.32 # Mikachu: yes, it's currently not doing anything useful other than testing 00.01.36 # (s/server/client/) 00.02.18 Quit `VL ("happines is a positive cache flow") 00.03.20 # I'm looking for someone who might help for my png viewer plugin 00.03.36 # Zagor: any reason it prints the full path for the .log and only the filename for the .zip? 00.03.46 # Mikachu: the idea with this new build client is that you can just run it an hour or two if you like and then kill it. 00.03.54 # Mikachu: no reason :) 00.04.17 # * kugel received 4 buils 00.04.18 # okay :) 00.04.37 # kugel: yes, the server feeds everyone four builds. 00.04.38 # Zagor: that's a major improvement imo 00.05.10 # BeChris: fwiw i have this super advanced plugin lying around http://comm.it.cx/?p=rockbox-svn.git;a=blob_plain;f=apps/plugins/bmp.c;h=288921c2c63d1a0212958bb698519f7291abe63a;hb=33d5e642cf73fad14b304064162cf1877a0ea9e4 00.05.24 # * Mikachu idly wonders why that url has two hashes 00.06.26 # New commit by 03bertrik (r21463): Fix more missing mutex_init calls. 00.06.29 # that probably doesn't help you :) 00.06.39 # Mikachu: I'm a bit farther than that :) 00.06.44 # hehe, okay 00.07.30 # Zagor: what are the () numbers, just process id? 00.07.35 # Even If you don't help, you might be interrested to test : see FS#9493 00.07.35 # yay, someone got killed :) 00.07.37 # child: sansac200 (27688) done 00.07.47 # Mikachu: yes, pid. debug leftovers. 00.08.01 # i was confused first because they happened to be close to current svn revs :) 00.08.09 # hehe 00.10.11 # Zagor: Can you follow what happens somewhere? 00.10.26 # yes I'm looking at the buildmaster output 00.10.46 # did you see me close mine? 00.10.48 # Actually, can *I* follow what happens 00.10.59 # rasher: no, not yet 00.11.09 # I spotted a bug in the master. restarting... 00.11.32 # * Mikachu thinks he had pretty good bugs found / time spent ratio 00.11.39 # uh nice 00.11.50 # very neat 00.11.50 # Zagor: What happens between the "Starting client" and HELLO? That takes a while.. 00.11.55 # Mikachu: heh, yeah 00.11.57 # it automagically restarted 00.12.20 # rasher: it tries to connect to buildmaster. I had the master down a couple of seconds. 00.12.37 # Ah, that would do it 00.13.33 Quit ender` (" On the contrary, if you never procreate, neither will your kids.") 00.14.27 # wow, the buildmaster bandwidth is a real bottleneck 00.14.34 # good thing we keep building! 00.16.36 # 100 builds not complete, 7 clients. 24 builds in progress 00.17.19 # urgh, why's it doing make -j$something? 00.17.28 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 00.17.36 # you'd probably want to be able to configure that 00.17.44 # maybe just use $MAKEOPTS? 00.17.45 # Or just respect MAKEFLAGS ... 00.17.47 # or opts 00.17.50 # it looks like it tries to pick a good thread number 00.17.54 # I always forget 00.18.13 # it reads /proc/cpuinfo and does -j cores+1 00.18.23 # why does it use zip instead of 7zip? 00.18.38 # i guess too much work to rezip on the other end? 00.18.39 # Sure, but why not just respect MAKEFLAGS? 00.18.41 # that's a question for the makefiles 00.19.41 # looking at MAKEFLAGS makes sense 00.20.06 # I mean, why do -j at all? Can't people set MAKEFLAGS as they please? 00.20.13 # easier 00.20.16 # .j is faster. we want speed. 00.20.41 # Zagor: You're overriding what I set in MAKEFLAGS. That's mean 00.20.57 # I agree, we should respect MAKEFILES. I'll look at that. 00.21.02 Quit nibbler_ (Read error: 110 (Connection timed out)) 00.21.03 # MAKEFLAGS, I mean 00.21.31 # But why not rely on that? 00.21.36 # Rather than doing the guessing 00.22.01 # usually it would be unset and waste 75% on new cpus? 00.22.07 # Do people not set makeflags? 00.22.08 # because then we have to make everyone set up MAKEFLAGS to get best speed. I'd rather have those who _don't_ want max speed set up exceptions. 00.22.13 # going to bed 00.22.15 # See U 00.22.29 # Actually I have make -j 4 00.22.31 # rasher: I think most people don't. 00.22.41 # Then they lack discipline! 00.22.46 # :) 00.22.51 # i didn't even know it existed, i have MAKEOPTS for gentoo though 00.23.03 # I think that's different 00.23.06 Quit BeChris ("Page closed") 00.23.21 # * JdGordon has -j6 set for the rbclient build.. and it freezes firefox when a build happens :) 00.23.24 # it's not very uncommon for makefiles to fail on parallel builds 00.23.45 # I wonder what's with the makeopts/makeflags thing 00.23.50 # man make only mentions makeflags here 00.23.55 # Mikachu: exactly. we mark each build mt-safe or not, and only run -j on mt-safe ones. 00.23.59 # opts is just a gentoo thing 00.24.03 # i just do make -j, it didn't seem much different then make -j4 00.24.15 # saratoga: how much ram do you have? :) 00.24.17 Quit bmbl ("Bye!") 00.24.19 # 4GB 00.24.37 # Zagor: I'd rather have the makefiles fixed.. 00.24.39 # -j forks massive amounts of processes. it runs _every_ file in parallell. 50-200 00.24.58 # rasher: it's not an either/or thing. 00.25.10 # also some targets simply don't benefit from -j, such as the manuals 00.25.16 # they are very linear 00.26.07 # If a build *fails* with anything but -j1, surely that's a bug? 00.26.15 # yes 00.26.24 Quit CathodeRayTube ("CGI:IRC (Ping timeout)") 00.27.07 # Are you hiding those bugs by not doing -j for them? 00.27.12 # Or did I just misunderstand 00.27.21 Quit bertrik ("De groeten") 00.27.34 # no. some targets don't run faster with -j, because they only run one command at a time 00.27.48 # in those cases it's better to build 4 different targets in parallell instead of running -j 00.28.05 # how hard would it be to do that? 00.28.07 Quit Nico_P (Remote closed the connection) 00.28.21 # Zagor: Ah so it's not so much mt-safe, as mt-useful 00.28.27 # saratoga: it's implemented already. not tested yet though. 00.28.31 # rasher: exactly 00.28.46 # * Mikachu only has the one core 00.28.47 # I can dig that 00.28.56 Quit n1s (Read error: 110 (Connection timed out)) 00.29.06 # kugel: Just a heads up: FS#10364 is still active. 00.32.03 # FS#9872 can go too if someone is doing that, an equivalent (but not the same diff) has been committed 00.32.13 # i put the details in a comment 00.37.08 # is the client now just building endlessly ? 00.37.42 # yes, it's just for testing. the server starts a new build round as soon as the previous has ended. 00.38.06 # will this work on cygwin? 00.38.24 # saratoga: Wellcome to slowtown. Population: you 00.38.39 # i've got a windows Pentium D machine sitting around here 00.38.57 # More than likely, you're better off running a vm 00.39.22 # I don't see any reason why it wouldn't work on cygwin though 00.39.47 # does "uname -o" work in cygwin? 00.40.19 # it returns "cygwin" 00.41.10 # good 00.41.55 Join Liam [0] (n=liam-mic@5ac3b706.bb.sky.com) 00.42.08 # Awrite, can someone help me? 00.42.14 # ok guys, thanks for testing. I'm shutting down buildmaster now. 00.42.27 # I want to change like the background of my ipod nano 3rd gen, was wondering how i'd do it/ is it possible? 00.42.33 # how close to ready is the new build system? 00.42.58 # Liam: Rockbox does not run on the nano 3rd gen. We cannot help you. 00.42.59 # pretty close. there's a few small issues with the build handouts in the master. 00.43.06 # Dammit 00.43.09 Part Liam 00.43.11 # and i guess user names and passwords 00.43.18 # right :) 00.45.23 *** Saving seen data "./dancer.seen" 00.45.48 # and ssl certs? or what is the idea? 00.46.18 # possibly ssl certs. we'll probably start with plain user:pass though. 00.50.56 # I'm going away on a one-week vacation on tuesday, so maybe we'll delay launch until I get back 00.53.03 Join Neovanglist [0] (i=Neovangl@69.31.129.33) 00.56.24 Quit Zagor ("Clint excited") 01.06.57 Quit trisiak (Read error: 110 (Connection timed out)) 01.07.56 Part safetydan ("Leaving.") 01.08.36 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 01.09.13 # * JdGordon doesnt know how to tackle his old(ish) wps ram usage patch.... try to figure out the killer bug? or start again? :'( 01.13.13 Join timc`` [0] (n=aoeu@116.3.197.244) 01.32.57 Quit timc (Read error: 110 (Connection timed out)) 01.33.13 Nick zitune is now known as zitune[afk] (n=zitune@bearstech/zitune) 01.36.23 Quit gevaerts (Nick collision from services.) 01.36.35 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 01.37.39 Quit Thundercloud_ (Remote closed the connection) 01.38.33 # JdGordon: I find restarting things often leads to me tackling certain details in new ways I hadn't thought of before. There could be other benefits from starting over too. 01.39.14 # yeah, im having a bit of trouble syncing it so maybe restarting is the way to go 01.40.46 Quit faemir (Remote closed the connection) 01.44.02 Quit stripwax ("http://miranda-im.org") 01.49.18 # nybody here have trouble playing FLAC's in rockbox? 01.49.32 # What sort of trouble are you having? 01.50.15 # it does a dump after a few seconds of playing it 01.50.17 # locks up 01.50.19 # gotta reboot 01.50.30 # On what device are you running Rockbox? 01.50.48 # IPOD Video 80GB but i upgraded the hard drive to 220GB 01.50.59 # or 240GB i think 01.51.03 # Have you tried the 30GB build? 01.51.12 # i had to do my own build 01.51.25 # because the sector size was too small in the 80GB build 01.51.27 # We don't provide support for custom builds. 01.51.43 # But you should try modifying a 30GB build instead and see if that helps 01.51.49 # Greek-Boy: Do other formats work OK, or do you just have FLAC? 01.51.59 # other formats work great 01.52.03 # its just a FLAC issue 01.52.10 # i used a SVN source to build 01.52.32 Join funman [0] (n=fun@rockbox/developer/funman) 01.52.39 # And the same FLACs play fine on a PC? Is there anything unusual about the FLACs? e.g. 24-bit? 01.55.03 # yeah the same FLAC's play 01.55.14 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 01.55.44 # I would still suggest first attempting a 30GB build. 01.55.57 # linuxstb: Forgive me for asking but where would I check if the FLAC is 24-bit? 01.56.48 Join Strath [0] (n=Strath__@173-23-45-236.client.mchsi.com) 01.57.22 # why would the 30GB build help if it was originally 80GB? 01.57.24 # Llorean: I wouldn't expect that to help - the codec buffer is loaded at the end of RAM, so I would expect it to crash immediately. Also Greek-Boy said other formats work fine. 01.57.46 # or did you misread the 8 as a 3? did i? :) 01.58.03 # linuxstb: Most problems with the build difference seem to show up "about 20 minutes in" which suggests it's end-of-buffer behaviour for some reason. you'd reach that much sooner with FLAC. 01.58.25 # Mikachu: Because many 80gb devices still have 32MB of RAM for whatever reason. Often they're refurbished. 01.58.32 # aha 01.59.07 # And it's a quick, simple test that can be got out of the way in a couple minutes. If it doesn't work, nothing too terribly costly lost. If it does, problem solved. 01.59.22 # definitely 01.59.30 # I wish I could check if its a ram issue or not. Is there a way to check the ram on the ipod? 01.59.42 # As I said, build a 30GB build and try it instead. 01.59.47 # if it's a RAM issue, the 30GB build will work fine. 01.59.52 # With sector size changes, that is 02.00.02 # Greek-Boy: 30GB ipods have 32MB ram and 80GB ones have 64MB, but maybe yours has 32MB 02.00.19 # If anyone here is working on the SanDisk Sansa View port, I would be interested in offering my sevices to further the cause. If not, any tips from others here on were to get started? 02.00.19 # if that wasn't clear from the above 02.00.21 # ok 02.00.38 # Strath: obo is working on it, you should ask him 02.00.39 # on another topic, will we see better video support in Rockbox in the near future? I thought I would be able to play DivX off it... 02.00.49 # Greek-Boy: unlikely 02.00.49 # thanks saratoga 02.00.59 # but hes been sending regular emails to the list with his progress, have you seen them? 02.01.30 # i've seen a few forum posts, but i don't think the email lists 02.01.38 # it is a gsoc project, right? 02.01.46 # Mikachu: I see. Well anyway its still a good solution for me. I want to be able to listen to FLAC's. Especially in my car... 02.02.05 # Mikachu: Can rockbox be connected to a kenwood head unit in ipod mode? 02.02.11 # no idea 02.02.23 # i don't have any accessories, even a dock 02.04.36 # ok 02.09.11 # Strath: i think more help disassemblying would be welcome 02.10.02 # Greek-Boy: BTW, you don't use an apostrophe for plurals - e.g. "FLACs"... 02.11.15 # linuxstb: Thank you for the info. :-) 02.20.25 Quit linuxstb ("Leaving") 02.20.39 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 02.30.03 Quit Cory` ("Leaving") 02.30.16 Join Cory` [0] (n=Cory@h3.176.89.75.dynamic.ip.windstream.net) 02.34.01 Quit martian67 (Read error: 54 (Connection reset by peer)) 02.35.07 Join martian67 [0] (n=xP@2001:470:b:356:221:91ff:fe8c:d8a7) 02.37.20 # rom disassembly? i can do that 02.38.35 # linuxstb: Whats the coolest thing that you do on your rockbox? 02.38.54 # saratoga: did you get my message about limiting Fuze RAM ? (padding current memory layout) 02.40.26 # Strath: just check the Sansa view wiki page linked from "status for work in progress ports", linked from the main page 02.40.38 Join cool_walking_ [0] (i=cb3b81c3@gateway/web/freenode/x-1ffdabecd1bf3972) 02.40.50 # I just posted another teeny patch at FS#10366. This one also removes nuisance debug messages. Please take a look. 02.40.52 # the current target is lcd support, it would make debugging much easier 02.41.33 # funman: yes but I forgot to try it since i didn't have a linux machine handy this weekend, will take a look now 02.42.20 # do you have a link to it in the logs? 02.42.22 # saratoga: i meet the same problem than on the clip on the c200v2 (which has 2MB of RAM, and a slightly smaller audiobuffer since it's color and the lcd framebuffer doesn't fit in iram 02.42.49 # ah found it 02.43.26 # http://www.rockbox.org/irc/log-20090619#14:14:39 02.44.15 # i started hacking but i think i need expert advise about buffering (i enabled logf in playback.c and buffering.c) 02.44.43 # perhaps FS#9332 would help also 02.45.27 *** Saving seen data "./dancer.seen" 02.46.30 # funman: does this look right? http://pastebin.com/m6b5c27e 02.47.36 # saratoga: yes looks very right : just check in debug menu -> buffering thread that you have something in the lines of 32kB audio buffer 02.47.59 # well i only consumed 5MB of RAM so i should have more then that right? 02.48.19 # if you use album art you might need a patched i have quoted on irc recently (but i'd like advice from someone knowing buffering like nico_p) 02.48.50 # my fuze build have ram usage: 1147176, so you migt need a bit more :) 02.48.58 # funman: have you tried shrinking the PCM buffer on the clip to see if that helps? 02.49.39 # linuxstb told me the PCM buffer should be at least 1s (like it is now) for crossfading to work. But he wasn't 100% sure about it. 02.50.19 # Anyway I think the PCM buffer should be much largest than the audiobuffer (at least 10 times more, since I think 10:1 is a common compression ratio for lossy codecs?) 02.50.22 # i get alloc is 77KB, is that the audiobuffer? 02.50.54 # alloc = x/available_audiobuffer 02.51.42 # x being the size of audiobuffer used by real file buffers, and additional buffers (like file descriptors) 02.52.14 # the available audiobuffer is the size of audiobuffer (seen in rockbox.map), minus the size used by voices, tagcache, etc .. 02.52.43 # my vorbis test file will play, but no mp3s will with 5MB of padding 02.53.06 # do you have pictures embedded in your mp3s ? (id3v2) 02.53.26 # no but there is one in teh folder its probably trying to load, let me remove it 02.54.10 # that fixed playback 02.54.21 Quit readability (Read error: 110 (Connection timed out)) 02.54.42 # there is an infinite loop when the buffer is too small for loading album art. I have a fix but again i'm not 100% sure if it's correct. 02.54.58 # shall i just loop for a while and see if it locks up? 02.55.05 # or maybe try a smaller buffer? 02.55.32 # how big is the available audio buffer ? (I think on the c200v2 it ranged from 30k to 50k) 02.56.09 # huh music just deadlocked 02.56.17 # I could even have a negative audiobuffer size when enabling logf and/or setting settings > limits to the maximum 02.56.32 # well the denominator in the buffering thread is still 77KB, should i get the number from rockbox.map? 02.56.35 # saratoga: so it justs enforces the theory that the bug is related to buffering 02.57.15 # yes it sounds like something is seriously wrong with buffering if the buffer is relatively small 02.57.48 # saratoga: in rockbox.map you can make the difference between audiobufend and audiobuffer, so you'll get the real audiobuffer size. But from that value you need to remove the bytes used by tagcache, talk, etc..) 02.58.25 # I think somehow the buffering is looping if there is not enough size available. 02.58.25 # now audio is quite screwed up, sounds like i'm only hearing the difference channel so that vocals are nearly attenuated but music is loud 02.59.06 # hm .. if you don't have a clip, here is how I (we, with bertrik at least) "fix" playback : stop, and resume, or power off, and resume. 02.59.19 # i have a clip 02.59.49 # if you have a clip you use regularly with rockbox (i use my fuze much more now :P ) 03.00.59 # the difference between audiobuf and end is almost exactly 1MB 03.01.16 # so that would probably explain why 2MB didn't work with the fuze 03.09.39 # funman: oddly enough, after rebooting into the OF, playing a file, and then rebooting back, audio works correctly again 03.09.44 # but just rebooting wasn't enough to fix it 03.09.52 # e200v2 for what its worth 03.10.12 # maybe i just have a bad headphone jack or something 03.13.10 # saratoga: if you haven't used much your clip recently, this might seem strange. But looks "normal" to me and clip users. 03.16.16 # i'm going to let it loop for a while and see if it deadlocks again while i'm not hitting buttons 03.18.27 Quit Cory` ("Leaving") 03.19.04 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 03.21.28 # Blue_Dude: Regarding your debugging output patches, why not simply replace DEBUGF() with logf() ? 03.27.34 Join trisiak [0] (n=tree@chello089078243195.chello.pl) 03.32.08 Join Strath_ [0] (n=Strath__@173-23-45-236.client.mchsi.com) 03.33.17 Quit d3v14710n () 03.46.23 Quit pixelma (Nick collision from services.) 03.46.24 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 03.46.40 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 03.46.57 Quit amiconn (Nick collision from services.) 03.47.00 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 03.47.21 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 03.49.23 Quit Strath (Read error: 110 (Connection timed out)) 03.54.02 Join Cory` [0] (n=Cory@h3.176.89.75.dynamic.ip.windstream.net) 03.58.24 Quit killan (Read error: 104 (Connection reset by peer)) 03.58.28 Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 04.00.47 Quit kugel (Read error: 110 (Connection timed out)) 04.04.34 Quit Cory` ("+++ OK ATH OK") 04.04.49 Join Cory` [0] (n=Cory@h3.176.89.75.dynamic.ip.windstream.net) 04.05.09 Quit Cory` (Client Quit) 04.05.20 Join Cory` [0] (n=Cory@h3.176.89.75.dynamic.ip.windstream.net) 04.23.13 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 04.23.42 # I will look again at recording on Sansa AMS tomorrow, i think it should be quite easy to implement 04.24.22 Quit funman ("free(random());") 04.36.08 Join toffe82 [0] (n=chatzill@70.235.226.56) 04.45.28 *** Saving seen data "./dancer.seen" 04.48.53 Quit dmb ("Leaving") 04.51.29 # linuxstb: There's no problem with that, except it would be nice to turn off logf when not building for a simulator. 04.55.21 Join dmb [0] (n=dmb@unaffiliated/dmb) 04.59.35 Quit _Auron_ (Read error: 110 (Connection timed out)) 04.59.36 Quit HellDragon (Read error: 104 (Connection reset by peer)) 05.05.31 Join HellDragon [0] (n=jd@modemcable178.248-201-24.mc.videotron.ca) 05.09.10 Quit dmb (Remote closed the connection) 05.10.34 Join dmb [0] (n=dmb@unaffiliated/dmb) 05.17.26 Quit dmb (Client Quit) 05.18.54 Join dmb [0] (n=dmb@unaffiliated/dmb) 05.20.07 Quit BHSPitMonkey (Remote closed the connection) 05.33.30 Quit soap (Read error: 60 (Operation timed out)) 05.38.10 # any chance of getting testers for FS#9886? 05.38.31 # I'm pretty sure its got some subtle bugs which my quick testing isnt showing up 05.45.23 Quit Horscht ("Verlassend") 05.53.51 # http://forums.rockbox.org/index.php?topic=22008.0 05.56.32 Quit Kopfgeldjaeger (Read error: 104 (Connection reset by peer)) 06.03.33 Join Lss [0] (n=Lss@cm33.zeta237.maxonline.com.sg) 06.04.53 Quit patmulchrone (Read error: 60 (Operation timed out)) 06.05.36 Join patmulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) 06.17.48 Quit timc`` (Read error: 110 (Connection timed out)) 06.20.27 Quit Strath_ ("Leaving") 06.21.36 Join n1s [0] (n=n1s@rockbox/developer/n1s) 06.22.19 # JdGordon: What happens when it uses less RAM? I'm assuming that doesn't mean "there's more buffer", is the RAM just sitting around unused (not a complaint, this is what I'd expect, it's just your post makes it sound like simple themes somehow free something up, which seems it'd cause problems if you changed to a complex theme *during* playback) 06.23.15 Join timc`` [0] (n=aoeu@221.201.146.40) 06.34.18 Part toffe82 06.39.03 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 06.40.20 Join killan_ [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 06.41.14 Quit killan (Read error: 104 (Connection reset by peer)) 06.45.29 *** Saving seen data "./dancer.seen" 06.53.31 # Llorean: yeah, i just realised i should elaborate more... going to do that now... 06.53.44 # when its finished the freed ram will be able to be returned to the audio buffer 06.53.46 # sort of.... 06.57.44 # Sort of? 06.57.49 # How will it work if playback is running? 07.01.52 Quit Llorean (Read error: 104 (Connection reset by peer)) 07.02.08 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 07.02.13 Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) 07.02.24 Quit Llorean (Client Quit) 07.02.34 Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) 07.05.36 # it wont work it playback is running.... (not untill our magicall not-malloc-but-re-allocalbla-alloc-buffer stuff happens 07.07.03 # Ah, so it's not really something useful until other work happens. I don't think users will like losing the ability to change WPS whenever they like without stopping. 07.09.45 # they wont 07.10.26 # anyway, we've had this discussion before and it was decided that its +'s were better than its -'s so when it works its going in 07.12.54 # * Llorean shrugs 07.14.30 # ... its in the logs, bassically the change wont affect users anyway if they dont touch the setting (or however its done)... but if people want crazy themes with 300K of images, they will be able to do that 07.14.50 # and when the wfm screen happens this can potentially soften its ram usage hit 07.15.04 # Setting? 07.15.38 Quit JdGordon (Remote closed the connection) 07.16.34 Join strikerz911 [0] (n=strikerz@cpe-72-229-115-164.nyc.res.rr.com) 07.17.50 Join JdGordon [0] (i=43a02c5a@gateway/web/freenode/x-37c15bb779dc6006) 07.17.55 # pigin crashed :/ 07.18.03 Part strikerz911 07.18.10 # Yeah, it's a bit unstable these days. 07.18.12 # it in all likelyhood wont be a true setting... 07.18.24 # What would it be. I'm a little confused, but i haven't tried the patch 07.18.25 # thats up for debate once this thing actually works correctly 07.18.56 # * Llorean shrugs. 07.19.00 # * Llorean never changes his WPS anyway 07.19.28 # ditto 07.23.42 Quit JdGordon ("Page closed") 07.24.14 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 07.30.23 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 07.35.44 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 07.36.27 Quit einhirn (Client Quit) 07.38.47 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 08.20.56 Join Rob2222 [0] (n=Miranda@p4FDCD426.dip.t-dialin.net) 08.21.55 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.28.18 Quit einhirn (SendQ exceeded) 08.35.33 Part safetydan ("Leaving.") 08.35.54 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 08.37.38 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 08.38.16 Quit einhirn (Read error: 104 (Connection reset by peer)) 08.38.30 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 08.39.00 Quit Rob2223 (Read error: 110 (Connection timed out)) 08.41.05 Quit einhirn (Read error: 104 (Connection reset by peer)) 08.41.21 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 08.45.30 *** Saving seen data "./dancer.seen" 08.50.10 Join kugel [0] (n=kugel@rockbox/developer/kugel) 08.52.09 Quit kugel (Remote closed the connection) 08.54.14 Quit einhirn (Read error: 104 (Connection reset by peer)) 08.54.36 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 08.55.54 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.58.43 Quit timc`` (Read error: 110 (Connection timed out)) 08.58.44 Join petur [50] (n=petur@rockbox/developer/petur) 09.00.30 Quit martian67 (Read error: 60 (Operation timed out)) 09.00.58 Join AndyIL [0] (i=AndyI@212.14.205.32) 09.02.23 Join timc`` [0] (n=aoeu@116.3.15.24) 09.09.02 Quit bertrik ("De groeten") 09.10.13 Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 09.12.16 Quit AndyI (Read error: 110 (Connection timed out)) 09.12.19 # is it just me, or are the forums running *damn* slow today ? 09.16.47 # I haven't noticed it. 09.18.02 Quit einhirn (Read error: 104 (Connection reset by peer)) 09.18.22 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 09.19.30 Quit einhirn (Read error: 104 (Connection reset by peer)) 09.19.50 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 09.20.29 Quit einhirn (Client Quit) 09.20.48 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 09.23.20 Join aliask [0] (n=chatzill@60-241-201-164.static.tpgi.com.au) 09.24.59 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.27.25 Quit killan_ (Read error: 110 (Connection timed out)) 09.41.22 Join nibbler_ [0] (n=Nibbler@pD9E31B06.dip.t-dialin.net) 09.41.48 Nick zitune[afk] is now known as zitune (n=zitune@bearstech/zitune) 09.44.24 Join Sir_Brizz [0] (n=brizz@c-67-169-249-174.hsd1.ut.comcast.net) 09.45.32 # Can anyone legitimize or disprove these two claims? 1) Rockbox won't let you charge your ipod through USB, 2) Rockbox syncs much slower than the standard ipod firmware 09.46.08 Quit Thundercloud (Remote closed the connection) 09.46.44 # 1) is a bug we're currently we're on, it's not that it "won't let you", more that "it doesn't and we don't know why". 09.46.56 # 2) I don't think that's true 09.47.56 # GodEater: On some ipods the USB writing is much slower 09.48.05 # in Rockbox as opposed to OF 09.48.18 # 4/5 MB/sec as opposed to 14 MB/sec 09.48.30 # AlexP: can't say I've noticed. Although I think I'm using the DMA patch, which does help :) 09.48.31 Quit Greek-Boy (Read error: 104 (Connection reset by peer)) 09.48.31 # That is 4 to 5, not 0.8 :) 09.48.45 # GodEater: The DMA patch helps hugely 09.48.59 # * GodEater waves the "commit it" flag 09.49.00 # With that it is not too far off the OF IIRC 09.53.18 # Sir_Brizz: The charging issue is why Rockbox USB is not enabled on the ipods for the releases, so that when you plug in USB it rteboots to the OF 09.55.41 # it doesnt reboot to of on the current builds right 09.55.44 # at least mine didnt 09.56.08 # well that stinks 09.56.11 # I'm consideringh loading it 09.56.19 # and yes my ipod 5.5 transfers faster on of 09.56.28 # 3rdly i can charge my ipod on rockbox 09.56.31 # mine';s an old ipod, not sure which gen 09.56.41 # in fact a weird thing is that on of it charges till 88 only 09.56.47 # while on rockbox it gets to 100 09.57.03 # Sir_Brizz: what do you mean "that stinks" ? 09.57.21 # that the charging doesn't work in rockbox 09.57.21 # rockbox is slower than OF on usb transfers 09.57.28 # erm i just said it does 09.57.29 # and that rockbox is slower 09.57.32 # on the current build 09.57.44 # i even have one of those portable battery packs which i use on the go 09.57.51 # while im still listening to the rockboxed ipod 09.58.07 # Sir_Brizz: but if you download the Release version it won't matter to you, since when you plug it into USB, you'll get the orignal firmware anyway, and so your ipod will continue to work fine. 09.58.15 # So I don't understand what difference it makes 09.58.20 # oh I see 09.58.26 # so even syncing would be "faster" 09.58.36 # faster than what ? 09.58.46 # well that's why I quoted it 09.58.56 # purportedly faster than in rockbox 09.59.03 # rockbox usb transfers are slower than OF usb transfers on my ipod 09.59.12 # by a factor of about 5 09.59.27 # Sir_Brizz: you won't be using Rockbox's USB code to sync at all though 09.59.31 # yeah 09.59.34 # that's what I mean 09.59.49 # once I plug in the USB charging and syncing will be on of 09.59.58 Quit CIA-70 () 10.00.17 # so if I put rockbox on and hate it, how hard is it to remove? 10.00.40 # its faster than the time you took to type that 10.00.42 # as hard as hitting an uninstall button 10.00.46 # haha fair enough 10.00.50 # the automated tool makes it really simple 10.01.02 # okay last question then, when I put rockbox on will it erase my files? 10.01.13 # no 10.01.18 # great 10.01.20 # but 10.01.27 # itunes stuff will require the database 10.01.36 # otherwise you cant access it 10.01.37 # so make sure you've read the manual 10.01.38 # protected files you mean? 10.02.04 # basically music you synced onto the ipod using itunes 10.02.09 # ah 10.02.15 # and you can pretty much kiss your videos bye bye 10.02.26 # rockbox isnt very good at video playback anyway 10.02.49 # rockbox is just fine at video playback on all ipods except the 5/5.5 gen thanks 10.03.52 # i remember that the format support means you had to re encode wasnt it 10.04.07 # yes, but what's that got to do with the actual playback ? 10.04.38 # having to settle for lower bitrates? 10.04.51 # Lss: Rockbox runs on about 7 ipods which don't normally play video, but play it well in Rockbox. You're assuming Sir_Brizz has an ipod video. 10.05.13 # nope 10.05.14 # good point will take note of that in the future 10.05.17 # this is an ipod color 10.05.43 # in which case a) you don't have videos on it at the moment anyway, and b) when you put some on their, they will look AWESOME!!!! 10.05.50 # s/their/there 10.05.55 # hehe :) 10.06.01 # okay I'm getting the installer 10.06.25 # is Rockbox Utility the preferred install method? 10.06.37 # the most pain free yes 10.06.38 # oh I guess so 10.06.39 # use it 10.06.49 # even the theme function works now 10.07.09 # Sir_Brizz: Yes - that's what the Rockbox manual suggests, and that's the definitive source for install and usage information. 10.07.27 # yeah I thought there were two installers for some reason 10.07.37 # Sir_Brizz: I would strongly recommend looking at the manual (to the point of insisting) :) 10.07.52 Join CIA-70 [0] (n=CIA@208.69.182.149) 10.08.54 # AlexP: is that the manual you insisted on breaking at the weekend ? :) 10.09.10 # Sir_Brizz: There are two installers, but they do the same thing (and actually use the same code). One is just a command-line tool for installing the Rockbox bootloader (ipodpatcher), rbutil does a lot more. 10.09.14 # its too long for most ppl to be honest 10.09.21 # ttdr haha 10.09.25 # tldr 10.09.50 # gotcha 10.09.53 # Lss: if you think you can condense it, please help us out 10.10.17 # the wiki is good enough imo 10.10.22 # rather than the full manual 10.10.34 # The wiki is full of outdated info 10.10.44 # And searching it is much much harder than the manual 10.10.44 # and is sometimes wrong 10.11.14 # i see 10.11.28 # let me look through 3.4's manual 10.11.29 Quit ChanServ (shutting down) 10.11.45 # 3.3 oops 10.11.53 Join ChanServ [0] (ChanServ@services.) 10.11.53 Mode "#rockbox +o ChanServ " by irc.freenode.net 10.11.53 DBUG sent MODE #rockbox -o ChanServ 10.11.54 *** Server message 485: 'logbot ChanServ #rockbox :User is immune from kick/deop' 10.14.52 # does the complete install install the fonts package? 10.15.34 # I can't remember to be honest 10.18.17 Nick zitune is now known as zitune[afk] (n=zitune@bearstech/zitune) 10.23.22 # Sir_Brizz: I think so 10.24.03 Quit nibbler_ (Read error: 110 (Connection timed out)) 10.25.07 Join martian67 [0] (n=xP@2001:470:b:356:221:91ff:fe8c:d8a7) 10.34.55 Join markun [50] (n=markun@rockbox/developer/markun) 10.36.15 Join blippe [0] (n=none_of_@213.136.34.23) 10.38.16 # i am trying to connect an itrip to ipod nano 1g with rockbox, is it possible to get it to work? 10.39.05 Join DarkSpectrum [0] (n=ZX@adsl-99-26-179-107.dsl.sfldmi.sbcglobal.net) 10.39.08 # blippe: we have a page in the rockbox wiki which says which accessories work and which don't 10.39.35 # http://www.rockbox.org/twiki/bin/view/Main/IpodAccessories 10.40.46 # GodEater: thanks... 10.43.48 # blippe: If yours isn't there it'd be great if you could add your findings so others can benefit in the future 10.45.34 *** Saving seen data "./dancer.seen" 10.46.55 # AlexP: np... 10.47.06 # cool 10.47.21 # Don't forget you might need options like the accessory power supply 10.48.56 # Thing is, the transmitter shuts down when i swithc from the apple firmware, but i think i read somewhere about shorting a connector so it is charged while rebooting, but i can't find the information anywhere. 10.49.15 # I am sitting with my soldering iron all set to go... :D 10.49.33 # er, search me :) 10.50.14 # anybody know a thrustworthy schematic over the connectors on a ipod nano 1g ? 10.50.54 # There may be something on the wiki, but I couldn't tell you where 10.51.04 # Or the ipodlinux wiki might have too 10.51.23 # i will have a look 10.53.29 # google suggests http://pinouts.ru/PortableDevices/ipod_pinout.shtml 10.55.13 # before i try to install it, does anyone know if the FS#9955 bootloader for the Sansa C200 works well yet? 10.55.45 # i was originally hopeing that the bootloader would have been updated for the 3.3 release 10.56.00 # bootloaders don't form part of the releases 10.56.25 # oh.... 10.57.03 # just seems a nussance to have to boot the player before connecting USB now that it's supported, if you plug it in with power off the OF boots 10.57.20 # yes, new ones would be good 10.57.20 # the bootloader will be updated when it's ready 10.57.36 # lol and i have 9 C200's and 7 E200's :P 10.57.45 # updateing is a pain ;) 10.57.57 # DarkSpectrum: I don't recall offhand, but the comments in the thread should tell if there are any problems that have been found 10.58.35 # i find it's always safe to ask, not everyone reports problems on FS but will tell you here sometimes 10.59.25 # yes 10.59.41 # I haven't heard of any, but that doesn't always mean much :) 10.59.48 # BTW, don't ask why i have so many players, i'm addicted to them, and hell at only $15 at microcenter i cant help but pick up another one every time i go there 11.00.31 # lol i even have a player glued to my monitor and use rockbox instead of winamp or anything else while on my computer :) 11.02.25 # ok to install that FS#9955 bootloader do i do the, "hold on, hold REC while powering on" and copy the .mi4 over to the emergency boot thing? 11.02.28 # DarkSpectrum, you may be interested to know rockbox can function as a remote while its plugged in 11.03.13 # yeah i saw that, but why bother, rockbox beats any audio media player anyway 11.03.42 # because losing the abillity to mix audio on your pc kinda sucks 11.03.45 # :) 11.04.15 # naw, i have c200 going to the line-in and back out to my normal speakers, so i can mix all i want :) 11.06.17 # martian67: oh, remote you say... how? 11.06.37 # blippe, a recentish build, plug it in 11.06.54 # its play/forward/back/pause/etc buttons 11.07.02 # map to keyboard multimedia keys 11.07.06 # ok i'm confused, where are the docs for sansapatcher? 11.07.27 # AlexP: seems as if port 17 (reserved) is used to power the itrip.. gonna try to short 17 and +3.3V and hope for the best... 11.07.27 # oh also volume 11.07.41 # martian67: win or lin? 11.07.47 # either it dosent matter 11.07.53 # its emulating a usb keyboard 11.07.59 # martian67: great, gonne check it out... 11.08.05 # you just have to have those keys mapped to do something on your system 11.08.16 # mine control foobar2000 :3 11.08.59 # martian67: foobar is the only thing i miss from windows. But i miss tons of stuff from linux on win, therefore: "portable ubuntu"... :D 11.09.05 # windows 11.09.09 # Let's stay on topic chaps 11.09.12 Join _lifeless [0] (n=lifeless@188.16.87.235) 11.09.17 # AlexP: sorry 11.09.22 # no problem :) 11.09.46 # blippe, foobar runs 100% fine in wine 11.09.48 # jfyi 11.13.20 Quit Cory` ("+++ OK ATH OK") 11.13.33 Join Cory` [0] (n=Cory@h3.176.89.75.dynamic.ip.windstream.net) 11.16.15 Join kugel [0] (i=kugel@rockbox/developer/kugel) 11.21.04 # could somone please help me find the docs for sansapatcher for windows? 11.21.08 # someone* 11.21.41 # Run "sansapatcher --help" - that's probably all the docs there are... 11.23.01 # ty 11.23.22 # i'm trying to figure out how to apply FS#9955 to my Sansa C240 11.23.35 Nick zitune[afk] is now known as zitune (n=zitune@bearstech/zitune) 11.25.09 # Copy sansapatcher.exe and firmware.mi4 to the same directory, and then run "sansapatcher -a firmware.mi4" 11.25.37 # assuming you've already built the new firmware.mi4 that is... 11.26.43 Join rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) 11.26.51 # GodEater: firmware.mi4 is attached to 9955 11.27.00 # * linuxstb sees that bluebrother has broken sansapatcher... :( 11.28.22 # linuxstb: so it's not actually a patch then 11.29.26 # GodEater: No, doesn't seem to be... 11.29.50 # silly me for assuming it was =/ 11.30.10 # Blame rasher... 11.30.11 # how do i go about installing it then, i do not use sansapatcher? 11.30.21 # DarkSpectrum: I just told you how to install it... 11.30.40 # you also said sansapatcher was broken ;) 11.30.44 # ok.. got confused again for a second 11.30.57 # * GodEater can understand DarkSpectrum's confusion in that case 11.31.08 # I assume svn sansapatcher is broken, not the already released executable 11.31.09 # GodEater: Yes, that's confusing... But DarkSpectrum can just use the latest released sansapatcher.exe 11.31.18 # And yes, I'm talking about current svn. 11.31.26 # AlexP: yes, I assume that too, but DarkSpectrum can be forgiven for not following 11.31.34 # GodEater: Indeed he can 11.31.40 # All is forgiven :) 11.31.44 # * linuxstb forgives DarkSpectrum 11.31.55 # lol ty 11.33.51 # kinda off topic, any future plans for WPS to support more then one font at a time? 11.34.05 # * rasher will accept no blame! 11.34.08 # it's one of those things that's on the "would be nice" list 11.34.18 # people have looked at it, there are patches. 11.34.29 # There's no category for "vanilla builds of rockbox (bootloaders)" 11.34.30 # DarkSpectrum: That's on topic IMO 11.34.31 # Torne: is that the same list as "feel free to write"? 11.34.41 # FrankTM: hehe 11.34.44 # well someone already did write it 11.34.48 # patch would be nice but i don't want to make a WPS that wouldnt be offically supported 11.34.49 # it's Mr. Someone's "TODO" list 11.35.01 # ahh. 11.35.05 # DarkSpectrum: a lot of the unofficial builds on the forum have the multifont patch 11.35.07 # DarkSpectrum: And it is wanted I think, it is just the existing patch doesn't do it properly, and nobody has written it to do it as it should 11.35.09 # i've been redirected to that a couple of time 11.35.11 # which, incidentally, got still longer at DevCon 11.35.13 # +s 11.35.25 # rasher: Also, was the version number incremented in the binaries, and did you make a note of the revision number? i.e. can we release those binaries as they are, or do they need rebuilding as releases? 11.35.33 # AlexP: maybe i'll look into modifying it 11.35.36 # * Torne needs multifont support to port frotz properly so would quite like it too :) 11.36.22 # DarkSpectrum: That'd be great - I'd bring it up on the mailing list first to find out how people would like it done so you don't potentially wate loads of time doing it the wrong way 11.36.26 # frotz needs multiple fonts ??? 11.36.30 # linuxstb: unfortunately no, I didn't. 11.36.39 # good idea 11.36.42 # GodEater: it's not mandatory but the z-machine has four hypothetical fonts 11.36.55 # one of which is unknown ;) 11.36.57 # I've never seen a z-machine games which uses them then. 11.37.01 # I'm bewildered 11.37.09 # quite a few infocom games use the graphics font 11.37.10 # and probably I've been chewed on by a grue 11.37.13 # to draw runes or maps and stuff 11.37.14 Join kugel_ [0] (i=kugel@141.45.205.72) 11.37.14 # rasher: Under the GPL I request the source for those bootloaders... ;) 11.37.15 # linuxstb: so we'd probably want a new round of builds anyway 11.37.23 # i hope noone is allready working on it, i've wanted a project to do besides making themes, and this is something i'd really want myself 11.37.26 # * rasher hands linuxstb a git checkout 11.37.38 # * linuxstb doesn't want it that much 11.37.43 # * GodEater wishes DarkSpectrum much luck 11.37.44 # almost all z-machine games use two fonts: fixed pitch for the top window, proportional for the bottom window 11.37.46 Quit cool_walking_ () 11.37.57 # Torne: shows my eye for detail then eh ? :) 11.38.06 # but i can do that without multifont if you pick a proportional font that vaguely matches sysfont in size 11.38.16 # DarkSpectrum: I don't think they are, and go for it! 11.38.34 # GodEater: unless you played lots of the original Infocom games you may not have noticed the graphics font :) inform games are unlikely to use it 11.38.39 # arent the GFX just extended ascii ? 11.38.49 # 127-254? 11.38.51 # no 11.38.54 # Torne: I think the original Zork is the only one I played. 11.39.02 # It was so hard it didn't inspire me to try any others 11.39.03 # 127-254 are used for accents to support european languages 11.39.11 # it switches to a different font entirely for fake gfx 11.39.18 # huh 11.39.32 # btw my frotz port runs, kinda 11.39.45 # i haven't implemented read_line yet but i can input characters by mapping buttons to particular keys 11.39.54 # which lets me run some of the z-machine spec compliance tests with good results 11.40.02 # scrolling is very veyr very slow though, i need to seriously optimise it :) 11.40.15 # zork on RB would rule if there was a good way to do it 11.40.38 # well i'm working on it 11.40.48 # AWSOME!!! 11.40.57 # i'll do what i can to implement a nicer UI after i have the zmachine running properly 11.41.19 # Torne: So how many different things are you working on? 11.41.28 # linuxstb: for rockbox, pretty much just this atm 11.41.41 # but i'm also doing two or three other projects for myself 11.41.43 # * GodEater doesn't want to try to use the virtual keyboard to play zork. I hope others will like it though. 11.41.45 # and contributing to two or three othe rplaces 11.41.47 # and having a job. :) 11.41.49 # how are you going to get around typing out what you want to do? 11.42.11 # DarkSpectrum: command lists, pick-from-screen typing, and just suffering nad having to type out what you want to do. 11.42.23 # it's not going to be particularly comfortable but I can probably do a bit better than the naieve implementaiton 11.42.23 Quit kugel (Read error: 60 (Operation timed out)) 11.42.24 # have a scrollable multiple choice or something? 11.42.26 # ahhh 11.42.37 # the main intention is to support games specifically written with limited input in mind 11.42.47 # but it will be a generic zmachine interpreter and thus can run any other zmachine game too 11.42.53 # Torne: Sorry, I was confusing frotz with frodo, and thought you were also porting a C64 emulator... 11.42.58 # ah. no. 11.43.05 # c64 is not my scene ;) 11.43.16 # sweet, i allready have a huge ZM dat collection 11.43.33 # naughty 11.43.44 # we do not talk about having copied infocom's games. :) 11.43.53 # (you can still buy many of them) 11.44.03 # lol i have bought them 11.44.20 # oh. sorry, i ay hav emisunderstood 'dat' :) 11.44.26 Join ironi [0] (n=ironi@cvitan.com) 11.44.28 # i've been playing zork since `83 on my first PC-XT 11.44.37 # anyway. yah. the majority of games will not be particularly fun to play 11.44.41 # but they *will work* 11.44.48 # at least, games in z5 format 11.44.56 # assuming you have a player with large ram 11.45.16 # z8 is too big to fit in the plugin buffer even on 64mb targets 11.45.20 # i have no idea what's in the C2xx and E2xx's 11.45.23 Quit CIA-70 () 11.45.42 # me either. you need a 512kb plugin buffer for my frotzbox at the moment 11.46.04 # it could be done in a lot less memory if I implemented swapping like the original zmachine interpreters used to but tha would make it a battery-life-sucker 11.46.18 # should work, i havent seen a plugin that hasent worked on them yet, except the mpeg player, runs too slow 11.46.26 Part ironi 11.46.28 # if lua runs then frotzbox will 11.48.20 # no idea, havent played with it yet 11.49.10 # yes, c2xx/e2xx will work 11.49.13 # at leas tin theory 11.49.17 # i've only tested it on ipodvideo 11.49.33 # when i've got a finished first iteration i'll post the code for people and you can try it 11.49.47 # can't wait :) 11.50.01 # sadly you will have to, as noted above i am perpetually doing ten things at once ;) 11.50.46 # hey late is better then naver ;P 11.50.51 # never* 11.51.01 # any thanks in advance to you also :) 11.52.06 Join kugel [0] (i=kugel@rockbox/developer/kugel) 11.53.09 # Torne: BTW, we're all fed up with plugins called rock* or *box ;) If it's a port of frotz, just call it frotz... 11.53.18 # Hehe 11.53.19 # alright 11.53.29 # i'll rename it later :) 11.55.54 # oh hey i saw that for GSoC they are working on WMA-Pro is that going to include WMA-Voice also? 11.56.45 Join CIA-71 [0] (n=CIA@208.69.182.149) 11.56.54 # No, WMA Pro wasn't an accepted project. 11.57.08 Join kugel__ [0] (i=kugel@141.45.205.72) 11.57.13 # oh 11.58.33 Quit einhirn (Success) 11.58.52 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 11.59.23 Quit einhirn (Client Quit) 12.00.25 # Torne: does your work have an FS # yet ? 12.00.34 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 12.04.33 Quit kugel (Read error: 60 (Operation timed out)) 12.05.08 # GodEater: no, i was going to wait until i had a bit more. 12.05.26 # posting a patch atm would be very tedious as i change it rather a lot :) 12.05.27 # Torne: bad developer. bad. Put it in now! 12.05.38 # aww 12.05.48 # with a patch? 12.05.55 # ideally 12.06.02 # i could link my bzr loom :) 12.06.15 # nothing stopping you doing that too in the comments 12.06.30 # not that anyone would be able to use it, i expect :) 12.06.34 # * GodEater goes to work out if he a) has bzr installed, and b) how the hell to use it. 12.06.34 # loom is weird 12.06.42 # loom is not a standard bzr branch either 12.06.58 # why not use git like a sane person ? :) 12.06.59 # i have all the pahces i use as threads on the loom so if you pull the whole thing you get a bunch of other FS# as well ;) 12.07.08 # because i find git horrendously difficult to use 12.07.14 # whereas bzr is made of delicious wonderfulness 12.07.22 # also it's written in python so when it breaks i cna fix it easily :) 12.07.38 # bzr can do svn interoperation just as well as git, so hey 12.08.13 # hm, actually, if i'm gonna post a patch there are some tidyups i need to do 12.08.37 # what's the policy on formatting/copyright notices/etc for files which are substantially just lifted from another suitably licenced project? 12.08.54 # frotz's code is hilariously old and every file is indented differently :) 12.08.55 Quit kugel_ (Read error: 110 (Connection timed out)) 12.09.36 # for plugins we don't care so much about the formatting 12.09.47 # Torne: I think generally, if the code is taken from somewhere else, follow the existing style in that file. Is frotz still being developed? 12.09.47 # the code has to be GPL compatible though 12.10.00 # GodEater: yah, iirc it's BSD, i did check this up front 12.10.05 # or MIT 12.10.14 # i'll double check it befor ei post it anywhere 12.10.30 # According to this, it's GPL'd - http://frotz.sourceforge.net/ 12.10.37 # linuxstb: it's not had a release for a very long time, but it's technically alive 12.10.48 # ah, ok then 12.12.20 # Torne: I guess it's up to you - the obvious downside of reformatting would be that it would be harder to sync changes. 12.12.40 # i'm unlikely to sync many, i have to say 12.12.45 # the last release was 10 months ago 12.13.11 # i might leave the files nicked from the core alone, but reformat the bits from dumbfrotz as i've rewritten half of that anyway 12.13.22 # the core stuff is supposed to be platform independant so needs very few changes to build for rockbox 12.13.28 # Sounds sensible. 12.13.56 # ok. i'll do that, rename it to just 'frotz', do something sensible with copyright/license notices 12.14.03 # and post a pathc of what i have so far on flyspray later sometime :) 12.17.36 Join kugel [0] (i=kugel@rockbox/developer/kugel) 12.22.27 Join kugel_ [0] (i=kugel@141.45.205.72) 12.25.16 Join Sajber^ [0] (n=Sajber@h-143-12.A213.priv.bahnhof.se) 12.31.04 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.36.01 Quit kugel__ (Read error: 110 (Connection timed out)) 12.38.15 Join kugel__ [0] (i=kugel@141.45.205.72) 12.39.33 Quit kugel (Read error: 110 (Connection timed out)) 12.40.48 Join kugel [0] (i=kugel@rockbox/developer/kugel) 12.45.35 *** Saving seen data "./dancer.seen" 12.56.02 Quit kugel_ (Read error: 110 (Connection timed out)) 12.56.44 Join kugel_ [0] (i=kugel@141.45.205.72) 12.58.34 Quit kugel__ (Read error: 110 (Connection timed out)) 13.00.05 Quit kugel (Read error: 60 (Operation timed out)) 13.07.05 Quit matsl (Read error: 110 (Connection timed out)) 13.07.25 Quit kugel_ (Read error: 60 (Operation timed out)) 13.07.35 Quit DarkSpectrum () 13.37.18 Join wark [0] (n=wark@fctnnbsc15w-142166071215.pppoe-dynamic.nb.aliant.net) 13.39.25 Join robin0800 [0] (n=root@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 13.50.55 Join nibbler_ [0] (n=Nibbler@pD9E31B06.dip.t-dialin.net) 13.54.43 Quit timc`` (Read error: 60 (Operation timed out)) 14.00.04 Join kugel [0] (i=kugel@rockbox/developer/kugel) 14.00.46 Quit jkl (Read error: 110 (Connection timed out)) 14.04.49 Quit martian67 (Read error: 60 (Operation timed out)) 14.10.15 Quit dmb (Read error: 113 (No route to host)) 14.11.52 Join d3v14710n [0] (i=d3v14710@unaffiliated/d3v14710n) 14.12.11 Join timc`` [0] (n=aoeu@221.201.170.125) 14.20.37 Join MarcGuay [0] (n=chatzill@ip216-239-92-56.vif.net) 14.21.34 # My favourite part of DevCon is all of the photos of scorche looking glum. 14.23.49 Join LambdaCalculus37 [0] (i=44a0430d@gateway/web/freenode/x-b5db3d0a6069018a) 14.29.26 Join funman [0] (n=fun@rockbox/developer/funman) 14.31.34 Join webguest31 [0] (n=5848dd1a@gateway/web/cgi-irc/labb.contactor.se/x-c59634fde370c17b) 14.34.31 # Could we have names/nicks at one of the group pics? 14.35.20 # webguest31: have you seen http://daniel.haxx.se/blog/2009/06/21/rockbox-devcon-2009-summary/ ? 14.36.04 # Ahh, missed that. Thanks. 14.39.53 Quit webguest31 ("CGI:IRC") 14.40.37 # funman: nerd alert :+ 14.41.05 # yes it didn't pass my nerd filtering ^^ 14.41.16 # nfi :) 14.41.39 # gevaerts: is MeizuM6Port up to date ? (no lcd support) 14.41.41 # wtf 14.42.00 # funman: the M3 has lcd, the M6 not yet 14.44.55 Join Blue_Dude [0] (n=chatzill@adsl-235-206-197.mco.bellsouth.net) 14.45.38 *** Saving seen data "./dancer.seen" 14.45.49 # linuxstb: I just posted a belated reply to FS#10366. 14.46.14 # Blue_Dude: It's not belated - I'm assuming we're in different timezones... 14.46.26 Join killan_ [0] (n=nnscript@213.112.250.14) 14.46.47 # I'm on EDT, and I finally turned in last night at 2am. 14.46.54 # GMT -4. 14.46.58 # What other file are you talking about? 14.47.02 # I'm GMT+1 14.47.20 Quit tvelocity ("Αποχώρησε") 14.47.21 # I originally cribbed the code from playback.c. 14.47.55 # And cut it down to make better sense in other files. 14.48.54 # IIRC the plugin API has changed a while back, and I kind of missed out on what the significant changes were. Can someone clue me in quickly on the changes? 14.50.09 # Also, I need to look for where the keymaps for each player are kept now. From the look of things (or maybe I'm looking in the wrong place), the #define's are not in the plugin main sources anymore. 14.50.10 # how long do you mean by a while? 14.50.28 # Torne: A while as in a couple of months. 14.50.31 # one thing that was done a while ago is that the rb pointer is provided and initialised automatically.. 14.50.46 # Blue_Dude: Ah, I was wondering where the name LOGFQUEUE came from. It seems to be used in playback.c to log messages posted to queues, so that name doesn't really make sense elsewhere. 14.50.48 # that was the only thing that caused me a problem updating the plugin i was working on :) 14.51.29 # Ah, I was thinking that it QUEUEs log messages for display. My bad. 14.51.43 # I'll go back and patch the patches. 15.00.13 Quit perrikwp (Read error: 60 (Operation timed out)) 15.01.19 Quit killan (Read error: 104 (Connection reset by peer)) 15.02.10 # LambdaCalculus37: Some plugins use the "plugin lib actions" business... Others have them in their main C file... Changes to the API, beats me.. I know you used to have to create your own reference to rb-> but now it's automatic.. 15.03.30 # MarcGuay: That's what I was thinking of. Thanks. :) 15.10.30 Join ocean [0] (i=d59c23f7@gateway/web/freenode/x-ce0ee84ab4be33d8) 15.10.53 Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) 15.12.13 # linuxstb: I posted a patch that should fix all three files. 15.12.29 Join jkl [0] (n=jlp@rrcs-24-213-137-226.nys.biz.rr.com) 15.26.57 Quit evilnick_home1 (Read error: 113 (No route to host)) 15.27.21 Quit aliask ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060309]") 15.32.18 # what *is* the best practise re plugin button mapping? 15.32.30 # i read somewhere that pluginlib actions is deprecated or at least advised against 15.32.49 Quit jkl (Read error: 113 (No route to host)) 15.35.45 Quit kugel (Read error: 60 (Operation timed out)) 15.36.17 # Unless the controls are very simple, PLA is likely more trouble than it's worth 15.40.04 # hmm im looking at the SansaAMS page and it says that all but USB and recording should be working on the Fuze V1, does that mean that it actually works well on this device? 15.41.47 # from what I understand, it works reasonably well. Depending on capacity there may still be bugs in the storage driver though (unless I'm misremembering) 15.42.06 # gevaerts: There are some bugs remaining IIRC. 15.42.16 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-4f78f96a1d1cc07d) 15.42.27 # I have 8GB internal and 8GB external for it 15.42.27 # But we should ask funman and kugel, since they're the ones doing all the dirty work. 15.42.35 # LambdaCalculus37: I said "reasonably well" :) 15.43.17 # lilltiger: I would not really recommend using the port just yet. While music playback is reasonably stable, the storage driver bugs may cause big issues. 15.43.54 # The front page will reflect when the port is ready to be used for everyday purposes. Right now, it's best left for developers to continue bug squashing. 15.45.28 # LambdaCalculus37: someone should add an note about it to the "http://www.rockbox.org/twiki/bin/view/Main/SansaAMS" as there is it would seem that there was no isses with it. 15.47.32 # lilltiger: I'll revise it when I get a chance. 15.47.48 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 15.48.18 Part n00b81 ("Leaving") 15.48.29 # cos imo the fuze is an awsome player, the only issue with it is the uglyness of the interface ;) 15.48.49 Quit MarcGuay ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 15.51.07 # lilltiger: Gotta give it time, though. Remember, we haven't got the ability to just hire robots to code for us all day, otherwise we'd all be sitting back on the beach of some tropical island, sipping exotic drinks, and be surrounded by beautiful women while the robots work and toil and speak for us on IRC. 15.51.20 # lilltiger: just read the requirements for release 15.51.28 Part LinusN 15.51.48 # funman: details are in flux right now :) 15.52.21 # i meant the "requirements for release" section of SansaAMS wiki page 15.52.33 # ah yes... 15.52.36 # funman: i did, but it dident say much :) and the chart implied that all was fine, thats was why i asked 15.53.11 # all is fine, except the bugs :/ 15.54.18 # funman: yes, but as the chart dident say any general problem for the V1 i had no way to know if the corruption/deadlock bug was related to the fuze v1 or not, so i askt :p 15.55.24 # I thought we decided at devcon that the AMS (and particularly the fuze v1) was going to become "supported" ? 15.55.53 # GodEater: as soon as there are no potentially player-bricking bugs left 15.56.06 # lilltiger: generally if the port isn't supported, these informations are for developers 15.56.19 # gevaerts: Which I think there are few last ones to squash, right? 15.56.35 # gevaerts: I got the impression from kugel that such a possiblity was extremely remote on the fuze now ? 15.56.56 # GodEater: gevaerts, there is no risk of bricking provided bootloaders are tested, but all the Sansa AMS suffer from storage corruption so i'm against it 15.57.16 # of course once this is fixed, no problem :) 15.57.18 # GodEater: it has sd corruption, and IIRC no always-working unbrick method 15.57.24 # fair enough 15.57.26 Join Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 15.57.47 # so you *probably* won't have serious issues, but if you do, they are bad 15.57.49 # only the e200v2 can be recovered, and that involves opening the case 15.58.15 # funman: ok, im used to use dev code and compile it myself on my puter, so i have an habit of checking the dev code. Guess it's a bad idea for mp3 players :) 15.58.37 # only for mp3 players you want to keep using ;) 15.58.55 # lilltiger: it depends. Some have *very* good recovery mechanisms 15.59.37 # lilltiger: i must say now the risk of bricking is very low if you don't mess with mkamsboot, but rockbox isn't just usable right now 16.02.01 Quit Kopfgeldjaeger (Client Quit) 16.02.21 Join Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 16.02.38 # what does the bricking cause that makes it unrecovable, ruining the bootloader i guess, but couldent the custom bootloader start with setting an bit, thats says something like, bootup failed, and then reset it at the end of the bootup. So if it fails while booting the bit will be set and it will fallback on the org bootloader. 16.03.00 # or does bricking imply something else then just an corrupt bootloader? 16.04.01 # a corrupted bootloader won't brick your player, because the dualboot is implemented in mkamsboot 16.04.20 # you could use /dev/urandom as a bootloader and still be able to boot the OF 16.04.27 # ahh ok 16.06.09 # I added a red note about storage on the page 16.06.22 Join martian67 [0] (n=xP@2001:470:b:356:221:91ff:fe8c:d8a7) 16.06.43 # funman: good alot clearer now 16.07.10 # thanks for suggesting ;) 16.07.27 # always happy to help with the important stuff :p 16.07.28 Join tvelocity [0] (n=tony@adsl15-233.her.forthnet.gr) 16.09.44 # funman: but what is corrupted when the fuze gets bricked, as you have an costum bootloader already in place, couldent that bootloader reload an working firware in case of failur? 16.10.31 # corrupted means that your player will not be functional and you have to format the partition 16.11.31 # funman: i ment for the bricking issues, as the sansa dosent include it's own unbricking i was thinking if there is a way for rockbox to implement it 16.11.51 # if it's bricked, it cannot run rockbox by definition 16.11.57 # it cannot run *anything* 16.11.57 # you're confused i think 16.12.20 # bricked can imply alot of things, all from broken booloader , broken firware etc. 16.12.26 # if you want to brick your player you can, but not with rockbox 16.14.15 # funman: can't the sd corruption make it overwrite the bootloader area? 16.14.41 # funman: i dont want to brick it, i was thinking about the possibilaty to implement an safeguard to recover from bugs that bricks the player 16.17.41 # gevaerts: i don't think so since we don't read or write to this area 16.18.01 # lilltiger: mkamsboot is that safeguard 16.18.24 # funman: ah, ok. That's good to know 16.18.38 # funman: ahh ok :) so only thing that can brick it is bugs in mkasmboot i guess? 16.19.31 # cos hopefully nothing else access that memory with the ability to write to it.. ;D 16.19.44 # lilltiger: yes, or like gevaerts mentioned a bug in rockbox which would overwrite the OF area (and there's nothing we can do here) 16.21.09 Join tvelocity[a] [0] (n=tony@adsl21-240.her.forthnet.gr) 16.21.34 # funman: ohh so the bootloader/firmware is on the same memory module as the "software" hehe thats quite a bad hardware design :) 16.21.56 # ok, i made a FS# for my frotz port, with a patch that actually builds and can run a z-machine compliance test program, at least on ipodvideo (not mapped buttons for other targets) :) 16.22.08 # FS#10370 16.24.34 # now it just needs line input, and to be less horrendously slow at scrolling, and it might almost be possible to run a game 16.27.05 Quit tvelocity (Read error: 60 (Operation timed out)) 16.28.44 # Torne: Does the compliance test succeed? 16.28.53 # mostly 16.28.59 # So, "no" ? ;) 16.29.05 # mostly it reports "the interpreter says FOO is not supported" 16.29.07 # which is valid :) 16.29.15 # but it should eventually support those things 16.29.21 # e.g. colour 16.29.36 # hilariously the main thing that goes wrong is because the compliance test is not compliant to the spec 16.29.46 # it tries to set the cursor position without checking that the screen is wide enough 16.29.53 # and ends up overwriting some of its own output :) 16.30.04 # presumably nobody ran it on such a narrow display before 16.30.11 # Where is this compliance test from? 16.30.15 # the frotz source 16.30.17 # or the ifarchive 16.30.43 # it's not very exciting/meaningful to someone who hasn't read the z-machine spec, tbh :) 16.30.51 # it only tests a few things 16.31.09 # but all the basics should Just Work as frotz's core is basically unmodified, it's only the text output stuff that i've written 16.32.13 # i don't recommend trying to run other z-machine programs because there's no exit button 16.32.24 # so if it turns out you don't have the right keys mapped to cause the program to exit voluntarily you will have to hardreset :) 16.32.55 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 16.37.33 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 16.37.39 Part n00b81 ("Leaving") 16.41.35 Join lazka [0] (n=lazka@84-119-73-94.dynamic.xdsl-line.inode.at) 16.42.01 # anyone here with a sansa fuze + sd card? 16.42.50 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 16.43.06 # I need to know if the sd card gets mounted as a seperate disk (e.g. in linux) 16.43.21 # lazka: it is, but this a bit offtopic :) 16.43.36 Join toffe82 [0] (n=chatzill@74.0.180.178) 16.44.55 # thanks very much.. that explains the second not working hal device.. 16.45.07 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 16.45.28 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 16.45.40 *** Saving seen data "./dancer.seen" 16.50.56 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 16.51.09 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 16.51.33 Join Jaykay [0] (n=chatzill@p5DDC64EA.dip.t-dialin.net) 16.53.33 Quit funman ("free(random());") 16.54.17 # i asked this a few months ago but forgot the answer... 16.54.40 # why do we (you) deprecate strings in lang files instead of deleting them? 16.55.05 # because if you remove a string halfway, older voicefiles stop working properly 16.55.39 Quit d3v14710n () 16.56.08 # so if you remove all deprecated strings and create new voice files everything is fine? 16.57.06 # not really. Lots of people make their own voice files 16.57.19 # so we try to avoid breaking them too often 16.57.22 # Yes, but then *everyone* will have to make new voice files. And there's no real gain. 17.02.47 # will voice files be broken too if you would delete deprecated strings which where also deprecated when the voice file was created? 17.02.47 # lazka: not working? my sansa fuze works flawless in linux registring the microSD as an removable vfat disk 17.03.38 # Jaykay: Yes 17.04.05 # rasher: can you explain why? 17.04.15 # There's really no use in deleting them. It would shave a few bytes off language files and voice files, but that's it. 17.04.22 Quit ocean (Ping timeout: 180 seconds) 17.04.28 # Jaykay: Because the order of clips in the files would be different from what rockbox expects 17.04.52 # lilltiger, never mind.. I'm fixing a bug in a media player which doesn't work right with the fuze.. and the cause is the sd slot 17.05.01 Join cg_ [0] (n=cromos@cable-kmi-fe71de00-186.dhcp.inet.fi) 17.05.23 Part lazka ("cya") 17.06.26 # rasher: i didn't ask you to delete them, i was curious :) and thanks 17.06.55 # Jaykay: basically each string gets an id, and removing a string changes the numbering 17.12.47 # the real problem is that voicefile dont really map the voice entry to the lang entry. It just expects them to be in the same order as the lang file. (thats also why we get wrong voice entrys when a lang files gets changed) 17.13.12 Join jkl [0] (n=jlp@pool-72-90-74-76.syrcny.fios.verizon.net) 17.14.02 # so sorting would also break voice files 17.15.02 # sorry, that should be a question :) 17.15.11 # yes 17.15.13 Quit Lss (Read error: 104 (Connection reset by peer)) 17.15.16 # Yes (but only the english language file, since that's the order that gets used when compiling) 17.15.32 # Other translations can be in any order 17.16.29 # anyone have any ideas on this one ? http://forums.rockbox.org/index.php?topic=21891.0 17.16.32 Join Lss [0] (n=Lss@cm33.zeta237.maxonline.com.sg) 17.17.03 # also adding a new string in the middle of english lang makes it break.. the voicefile system could need some improvements :-) 17.17.20 # domonoky: I think the fix is "don't do that" 17.17.28 Join Chesteta [0] (n=Chesteta@customer-67-148-163-64.citescape.com) 17.18.05 # the real fix would be to make some header to the voice file to really map them to the lang file, and that we are able to detect when they wont fit anymore. 17.19.03 # I'm not convinced the current situation is so bad 17.20.13 # domonoky: is it a "problem" of rockbox or of... something else? 17.20.52 # i think its bad, that we are not able to detect when a voicefile wont fix anymore. 17.21.20 Join kugel [0] (i=kugel@rockbox/developer/kugel) 17.21.26 # rockbox could play some "voicefile invalid" thing and rbutil could inform the user to generate a new one. 17.21.41 # s/fix/fit. 17.22.22 # GodEater: My guess - cable's bad. It sounds like it's treating a USB port like a charger, which may just mean the data bit is cut but the power bit isn't. 17.22.52 # Llorean: you already told him that didn't you? I'll reiterate it. 17.23.49 # Well, I *just* told him that, yeah. 17.24.06 # In his case, with a c250, replacing the player might actually be the same price as buying a cable on its own though. 17.24.54 # he might get a v2 though ;) 17.25.57 Quit Chesteta (Read error: 60 (Operation timed out)) 17.26.05 # we need more people who have a c200v2 anyway :) 17.26.46 Join CaptainKwel [0] (i=2669ecc2@gateway/web/freenode/x-cdcb8db58088f710) 17.26.50 Quit markun ("going back to Enschede") 17.37.47 Quit flydutch ("/* empty */") 17.41.31 # can someone explain "Set PCM buffer size to what is actually needed." to me? especially what pcm buffer is 17.41.46 # GodEater: he could try to start up his puter with an linux live cd and check what info it gives about the device connected to the usb port 17.42.36 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 17.43.01 # Jaykay: The PCM buffer is what holds music after it's decoded, but before it's played. 17.43.30 # It mainly helps make sure that if decoding takes a little longer than expected (high CPU-cost chunks in VBR files, or when the disk is just spinning up to rebuffer) there are no skips or gaps 17.44.12 # so this is the audio buffer and should be as big as possible right? 17.44.22 # No. 17.44.41 # It should be as small as we can make it without impairing its functionality. 17.44.49 # As I said, it's for *after* it's decoded. 17.45.13 # The compressed buffer is the one that should be as large as possible. 17.45.25 # Both of them contain audio, just in different forms, so it's better to avoid calling either of them "the audio buffer" 17.46.05 # yes, but one of the is called that everywhere anywa 17.46.12 # y 17.46.21 # gevaerts: Yeah, the compressed one. 17.46.57 # "compressed" isn't even always accurate anyway 17.47.08 # since you can buffer WAV or AIFF uncompressed formats. 17.47.15 # is there anything else besides rockbox itself, the compressed one and pcm buffer in ram? 17.47.24 # the PCM buffer is an device buffer, is it should be named device audio buffer if mentioned :) 17.47.34 # lilltiger: What do you mean "device buffer"? 17.47.56 # Jaykay: Could you clarify, there's some grammar difficulty at the end of that sentence that makes you unsure what you mean. 17.47.57 # Jaykay: sure. plugin buffer, codec buffer, and various other things that get enabled by certain options 17.47.59 # Llorean: and buffer that is derectly used by an hardware device, like the PCM 17.48.42 # lilltiger: There's no device called "the PCM." PCM is a way of representing audio data as digital data, and the PCM buffer is just a portion of RAM we set aside for holding PCM formatted audio (which is what you get after decoding the compressed audio) 17.49.37 # what does the codec buffer contain? a "description" how to decode the data in the compressed buffer? 17.49.50 # Llorean: ahh sorry, i just assumed rockbox handled it like linux does, guess not then 17.50.18 # Jaykay: It contains the codec in use. 17.52.49 Quit kugel (Nick collision from services.) 17.52.53 Join kugel [0] (n=kugel@e178064040.adsl.alicedsl.de) 17.58.41 # So, does anyone think FS#10093 is a bad idea? Apart from the fact that it sadly doesn't and can't work for themes? 17.59.12 Quit kugel (Nick collision from services.) 17.59.18 Join kugel [0] (n=kugel@e178077053.adsl.alicedsl.de) 18.00.06 Quit timc`` (Read error: 60 (Operation timed out)) 18.01.19 # rasher: re dirfilter=0, what if you browse fonts using the filebrowser? 18.02.09 # I think it's a nice addition 18.02.58 # kugel: Then SHOW_FONT won't be set 18.03.18 # ah yea, that makes sense 18.04.15 # Something tells me this could be done in a simpler way, but I can't really figure out how 18.04.23 # rasher: I like it a lot 18.04.25 # just remove the DEBUGF before committing :P 18.04.32 # kugel: yeah, just noticed that 18.04.36 Join AndyI [0] (n=pasha_in@212.14.208.235) 18.04.38 # It basically makes fonts, etc, appear to be identical to settings. 18.04.59 Quit Lss (Read error: 104 (Connection reset by peer)) 18.05.01 # I think it could work for themes, storing the filename in nvram.bin or something 18.05.24 # kugel: Except you'd need to reset it if *any* theme related setting changed anyway 18.05.35 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 18.05.39 # Since you can set font color, .wps, font, backdrop, etc independently of theme.cfg 18.05.59 # A theme is just "the last loaded .cfg file" really 18.06.17 Join ocean [0] (i=d59c23e8@gateway/web/freenode/x-c9b6c5c5f77785b6) 18.06.18 Join Lss [0] (n=Lss@cm33.zeta237.maxonline.com.sg) 18.06.21 # Maybe "Browse fonts" should be changed to just "Font". This should also make it somewhat more obvious why Browse themes behaves differently 18.06.34 # rasher: That's probably a good thing to go with it yeah. 18.07.10 # well, I can imagine that a) you don't obfuscate the theme enough to make it count as a different one, or b) you are quite happy to see which it was based off if you obfuscated it 18.08.10 # not much of an issue though, I think 18.08.38 # Or c) you're a user who doesn't understand themes are just .cfg files and file a bug report saying "Why does it say my currently selected theme is "Cabbiev2" when I selected the BlackMP.wps last week from 'browse WPS'"? 18.09.13 # I don't think he'll be aware of the last phrase 18.09.15 # I think for .cfg files (themes, and settings groups) it's better just to make sure the user knows they're browsing a file, and for things like Fonts where they really don't need to know it's a file, drop the "Browse" keyword since it's irrelevant. 18.09.27 # the bug report will more be like "Why does it say my currently selected theme is "Cabbiev2"" 18.10.12 # * rasher will also change "Browse Themes" to "Browse Theme Files" 18.10.17 # on the other hand, users may also report a bug on "Why isn't the theme I loaded selected" 18.10.57 # rasher: if WPS, RWPS or FM Presets have "Browse" it should probably be dropped there too 18.11.25 Nick zitune is now known as zitune[afk] (n=zitune@bearstech/zitune) 18.11.35 # rasher: "Browse theme configs" maybe? 18.11.48 # Or "Browse theme settings"? 18.12.02 # Nah, neither of those really works well 18.12.17 # Llorean: Already changed wps and rwps, fm presets are "Load Preset List", which I guess works 18.12.35 # "Select preset list" maybe? 18.12.38 # Or even "Choose preset list"? 18.12.45 Quit AndyI (Read error: 113 (No route to host)) 18.13.01 Join AndyI [0] (n=pasha_in@212.14.208.235) 18.13.21 # I'd drop the "list" 18.13.41 # I think I'll just leave it. It's not really related to this change 18.14.09 # kugel: You aren't choosing one preset. 18.14.12 # Your choosing one group of presets. 18.14.27 # I know, but how does that matter? 18.14.32 # If you drop the word "list" it means something very different entirely. 18.14.38 # One preset is "106.9 KRBE" 18.14.45 # "Load Presets"? 18.14.51 Quit AndyIL (Read error: 110 (Connection timed out)) 18.14.55 # that's what I was thinking 18.14.59 # One preset list is several different presets associated with different stations 18.15.02 # A theme is also a list of settings, we don't call it list either 18.15.09 # You'd load houston.fmr and that's the preset list for all presets in houston 18.15.44 # Have you used the FM Radio much? 18.15.46 # It's not a list of settings. 18.16.02 # it's still one file. You click on 1 file, which is to me: load one thing, not caring about what actually is in that file 18.17.04 # There's a difference between "one file" and "one setting" 18.17.15 # It's not? What is it then? It clearly lists some settings with their value to be applied 18.17.25 # In every other case, each "file" you load changes a single setting. In the case of the theme.cfg it changes many settings, just like running a "Manage settings" style .cfg does 18.17.39 # kugel: Really? What settings does it list? 18.17.40 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.17.56 # font, colors and stuff 18.18.12 # No, the FM preset is not a list of settings 18.18.24 # I said a theme file is also just a list 18.18.32 # The fm preset is *not* just a list though 18.18.34 # and we don't call it list 18.18.36 # Which is what *I* said 18.18.45 # The fm preset is a list of stations, it doesn't change multiple settings 18.18.54 # A theme file changes multiple settings, it's not a list of settings-independent values. 18.18.58 # They're two entirely different things. 18.19.01 # how does setting or not change it being a list? 18.19.29 # We don't call it a theme list because it's not a list OF THEMES 18.19.33 # It's a single theme 18.19.39 # We could call it a "theme settings list" if you wanted 18.19.50 # But a single preset is different from a list of presets 18.19.54 # Calling it "a preset" is incorrect. 18.20.01 # No, I don't want. The word list isn't needed at all imo 18.20.04 # A list of X is not the same as "an X" 18.20.17 # Do you understand the concept of a difference between singular and plural? 18.20.29 # "Load presets" (with the 's', i.e. 1 item is presets) works fine 18.20.37 # You didn't say "rename it to Load presets" 18.20.39 # You said "remove the word list" 18.20.46 # Sorry" drop the list" 18.21.36 # alright, I meant changing to "presets" in the same run (see my respond to rasher), I've should've been more clear in the first place, sorry 18.21.37 # Actually, I think the word list makes sense, because it makes it obvious that there can be multiple lists of presets, which is less obvious if you just have "Load Presets" 18.21.47 # what would be a good PWM frequency for backlight dimming? 18.22.01 # I need to process two interrupts per PWM period 18.22.25 # rasher: the current list doesn't mean there can be more than 1 list 18.22.29 # and what would be a good amount of backlight dimming steps? 18.22.33 Quit daurn (Read error: 110 (Connection timed out)) 18.22.50 # bertrik: trial and error seems the best way to find out 18.23.08 # basically so that you meet the current settings 18.23.47 # kugel, does backlight dimming do 1 backlight step per tick or something? 18.24.06 # are you after PWM fading or SW fading? 18.24.20 # PWM fading 18.24.34 # that one does several pwm adjustments per tick 18.24.37 # I get an interrupt when the desired percentage is reached and another interrupt when the full period is reached 18.25.55 # rasher: You mean the "list" makes clear that you're about to list a list of presets? 18.26.13 # kugel: Err, yes. I think that's what I mean 18.26.16 # also I wonder how the backlight dimming steps should be spaced 18.26.29 # We don't do this anywhere in rockbox 18.26.39 # PWM is probably as linear as you can get, while human perception is probably more logarithmic 18.26.41 # imagine "Volume list" 18.27.06 # people aren't expecting that list is related to "the screen will be a(nother) list" 18.27.48 # kugel: Maybe that's not what I mean. No, it's not. I mean that "Load presets" just seems to imply that entering that will load some amount of presets, where as "Load Preset List" means that there are a number of lists you can pick from 18.28.02 # That's what I mean 18.28.35 # The "List" specifies that each item is a list, not that the menu you enter is a list 18.28.38 # We aren't using the word list to announce a list where you can select an item from anywhere 18.28.47 # Yes, you have multiple sets of multiple presets, not just multiple presets. 18.29.17 # so that's not what you're putting into the word list, hence " I think the word list makes sense, because it makes it obvious that there can be multiple lists of presets" doesn't really make sense to me 18.29.38 # kugel: But that's not what this does. It just says "The list you're about to see consists of lists" 18.29.43 # kugel, OK I think I'll just pick some compromise between not too fast and not too flickery 18.29.46 Join daurn [0] (n=daurnima@unaffiliated/daurnimator) 18.30.08 # rasher: yea, that's how it's meant currently, but I don't think it's really needed 18.30.31 # But it's correct. 18.30.36 # That's what it is, a list of the names of lists. 18.30.41 # I never said it's wrong 18.31.00 # I think it's better than leaving it out, since removing it makes is less clear what happens when you enter that menu-entry 18.31.19 Quit cg_ ("leaving") 18.31.29 # you mean when you select something after entering that menu-entry? 18.31.57 # No 18.32.03 # I mean when you select that menu-entry 18.32.18 # "Load presets" could mean it just loads some presets from god-knows-where 18.32.42 # "Load preset list" makes it more clear that you get to pick a preset list 18.32.51 Join cg_ [0] (n=cromos@cable-kmi-fe71de00-186.dhcp.inet.fi) 18.32.51 # the word "list", which means that each submenu entry is a list, makes clear that the submenu as a whole is also a list? 18.33.33 # that doesn't make much sense to me, since, as I said, we nowhere else announce submenus being a list with the word list 18.33.34 Quit petur ("work->home") 18.33.44 # No, that's not what I'm saying 18.33.55 # "load preset list" kinda implies "which preset list?" 18.34.10 # "load presets" doesn't imply "which presets?" so much 18.34.14 # Torne: Yes, do you want the list of presets for houston, or the list of presets for dallas? 18.34.18 # so does "Load presets" imples "Which presets" IMO 18.34.28 # You aren't getting a single preset, you're getting a single list of prests when you select something 18.34.30 # imply* 18.34.32 # kugel: well, yah. it's a matter of opinion, since of ocurse formally it means no such thing 18.34.40 # kugel: but i have to agree with rasher, sounds like it to me 18.34.55 # we could argue that way for many other settings in rockbox 18.35.00 # Llorean: yah, i'm agreeing with you :) 18.35.20 Join AndyIL [0] (i=AndyI@212.14.205.32) 18.35.36 # so the word list has a double meaning for you, while it only has 1 (what it's supposed to mean) for me 18.35.44 # it's not the word list 18.35.48 # it's just the way it's phrased 18.35.52 Join JdGordon| [0] (i=836b0049@gateway/web/freenode/x-95ab2e85fd537619) 18.36.02 # "load preset file" would imply the same thing to me 18.36.04 # kugel: So you disagree that each fmr file is a preset list? 18.36.07 # that you had to pick which file 18.36.19 # Llorean: How come you think that? 18.36.22 # "load presets" sounds vague/abstract, it doesn't sound likely to ask me aything 18.36.41 # kugel: Imagine "Load preset file" instead, substitute file with list, but with the same meaning 18.37.00 # The fact that it's the word "list" is confusing things in this discussion, I think 18.37.04 # "load presets" sounds similar to "load factory defaults" or similar :) 18.37.09 # i.e. something i won't get a choice about 18.37.16 # rasher: indeed 18.37.21 # Llorean: It means to me that you get to choose preset lists 18.37.29 # kugel: And you are choosing preset lists. 18.37.30 # so each file in there is a list 18.37.33 # Each fmr file is a preset list. 18.37.37 # ... 18.38.54 # I'm really confused by what your objection is. 18.38.57 Quit kugel (Nick collision from services.) 18.39.03 Join kugel [0] (n=kugel@e178083048.adsl.alicedsl.de) 18.39.17 # You agree that you get to choose preset files. You agree that each preset file is a list. Transitively, you're choosing a preset list. 18.39.23 # I don't see why you don't agree to the third point. 18.39.32 # What am I missing? 18.39.56 # I'm saying the word list isn't needed, and that Load presets works just as fine 18.40.30 # But what you see isn't a list of presets. 18.40.34 # I can't load an individual preset. 18.40.36 # I never said that the word list is wrong or something 18.40.50 # kugel: some of us are saying "it's more obvious what it means if it says list" 18.40.58 # it's a list of list of presets 18.40.58 # so what's the actual argument for removing it? 18.41.02 # it might be redundant to you 18.41.06 # but clearly it has value to othre people 18.41.14 # Yes, it's a list of lists of presets. that is not the same as "a list of presets" 18.41.16 # do you really want to save the five bytes that much? :) 18.41.19 # for me, it's the same as a list of presets (each fmr is presets 18.41.20 # ) 18.41.53 # Torne: no, I don't actually care about it at all 18.42.04 # then why are we even having this discussion? :) 18.42.05 # just defending my opinion for whatever reason 18.42.29 # Torne: because apparently some people think I'm not aware of the fact that each .fmr is a list 18.42.35 # ok. mutual understanding has been reached 18.42.37 # so we can stop? 18.43.05 # I think so 18.43.18 # * gevaerts supports Torne's proposal 18.45.44 *** Saving seen data "./dancer.seen" 18.46.31 Join javacris [0] (n=pao@82-160-42-100.tktelekom.pl) 18.46.50 # ..what frequency is the tick? 18.47.02 # * Torne feels dumb for not being able to find it 18.47.05 # 100Hz I think 18.47.05 # 100 18.47.21 # i.e. "#define HZ 100" 18.47.39 # ok i'm dense 18.47.44 # it's not like i'v enever used HZ 18.47.58 # Hi, I have Question about buttery runtime h300 series 18.48.24 # The question itself would be more interesting 18.48.27 # is truth that rockbox works longer then OF 18.48.51 # javacris: http://www.rockbox.org/twiki/bin/view/Main/IriverRuntime 18.49.06 # kugel: Hi. linuxstb suggested some cleanup from the debug fixes yesterday. The cleanup patch is in FS#10366. 18.49.32 # I saw this site, but theres no battery bench with newest rockbox builds 18.49.48 # rasher: feel free to annoy me tonight to look at 10093... assuming you want someone to give it a once over? 18.50.05 # it's generally not getting noticeably worse, but feel free to update the page with a recent result 18.50.34 Join archstech [0] (n=archstec@206.251.250.215) 18.51.13 # Blue_Dude: I think the "sdl_audio_callback: No Data.\n" should stay 18.51.28 # JdGordon|: I'm fairly happy with it by now actually.. mostly I'm worried that the code could be more efficient. 18.51.29 Join dlctestnt [0] (n=dlctestn@206.251.250.209) 18.51.38 # kugel: OK. I'm not convinced it's an error though. 18.51.38 # and I can't remember seeing any of the others yet 18.52.07 # Blue_Dude: it can show unexpected audio stop too 18.52.09 # kugel: The others only occur when --debugaudio is active. 18.53.24 # kugel: So should they be DEBUG again, or should logc be enabled by default in that file? 18.53.44 Part javacris 18.55.44 Quit AndyI (No route to host) 18.56.18 # hm. repainting the screen takes 0.15 seconds while unboosted, then 18.56.22 # that's kinda slow 18.56.29 Quit ocean (Ping timeout: 180 seconds) 18.56.38 # explains why scrolling the entire screen one line at a time sucks so hard :) 18.57.44 # Torne: if you don't need to do that too often, just boost for the duration 18.57.45 # i need a better buffering strategy. 18.57.46 # Blue_Dude: so, say the one stays, and the other are only with -debugaudio, nothing would change actually (except needing an extra define)? 18.58.07 # gevaerts: the problem is that it scrolls one line at a time 18.58.13 # if it scrolled the screen all at once that'd be fine as it is 18.58.19 # 0.15s is horribly slow, which target is that on? 18.58.21 # Torne: yes, but probably only if someone does something 18.58.26 # but scrolling up 30-odd lines for the entire screen means repainting 30 times 18.58.35 # which is immediately 4.4s 18.58.39 # you could run test_fps to see the real refresh time 18.58.40 # Torne: Do you need to scroll? Can you just redraw everything instead? 18.58.43 # kugel: this is printing text 18.58.46 # Smooth scrolling isn't liked by everyone anyway 18.58.47 # Llorean: this is redrawing. 18.58.55 # i don't get a choice 18.58.58 # it's a text console 18.59.01 # Torne: but I mean, step everything up one whole line, then redraw the screen once, rather than scrolling. 18.59.07 # I am doing that 18.59.11 # i'm not scrolling the grpahical data 18.59.15 # i'm buffering the text as text 18.59.19 # scrolling that in the text buffer 18.59.22 # then repainting the screen. 18.59.26 # the repaint takes 0.15s :( 18.59.28 Join Ubuntuxer [0] (n=johannes@dslb-094-221-094-174.pools.arcor-ip.net) 18.59.38 # I can't really believe that 18.59.40 # the interpreter doesn't know how many more lines are going to be printed before the next prompt 18.59.45 # I don't know what your code is like though 18.59.46 # Torne: What target? 18.59.49 # ipod video 18.59.55 # kugel: it's a slow hack :) 18.59.59 # it's printing one character at a time 19.00.01 # for an entire screenful 19.00.07 # That's basically the slowest screen/processor combination. 19.00.10 # doing seperate utf8 encode/decode for each character 19.00.13 # At least you're looking at a worst-case. 19.00.31 # yah. the problem is that i'm repainting on scroll 19.00.35 # i probably shouldn't 19.00.42 # Torne: http://www.rockbox.org/twiki/bin/view/Main/LcdFrameRate lists a better redraw time 19.00.45 # i should be lazy and repaint just when everything stops :) 19.00.54 # kugel: this is a *text buffer with formatting attributes* 19.01.00 # being output one character at a time with lcd_putsxy 19.01.02 # so? 19.01.06 # it's nothing to do with the time lcd_update takes 19.01.13 # lcd_update just writes the framebuffer to the hardware 19.01.15 # itg's the time it takes to do all the messing around with fonts 19.01.26 # it doesn't matter what's in the frame buffer 19.01.36 # it's not the lcd_update that i'm timing 19.01.43 # what's repainting then? 19.01.45 # it's the process of calling lcd_puts all those times 19.01.51 # my code, repainting the text console 19.02.05 # kugel: Something like that. I put in the --debugaudio outputs in myself last week and they're not too obnoxious. I was mainly targeting the sdl debug output, but if it's necessary then there no real point in patching that file. 19.03.02 # kugel: i'm not complaining about any part of rockbox, to be clear 19.03.14 # *my code* is too slow, because the zmachine is dumb and i've implemented it in a naieve way 19.03.14 # Torne: so repainting is the whole thing, except for the just added line? 19.03.42 # Torne: You just want to scroll the text up one line? 19.03.43 # yah. it has to lcd_putsxy() every single character on the entire screen again, just to scroll up one line 19.03.49 # linuxstb: yup :) 19.03.50 # the meizu m3 has a little piezo speaker connected to two pins 19.03.58 # is there anything in rockbox that could use that? 19.04.11 # keyclick maybe? (that's what the OF seems to use it for) 19.04.17 # yes 19.04.20 # i think i need to just not draw anything on the screen at all until the user gets prompted for input 19.04.22 # that would be nice 19.04.25 Quit JdGordon| (Ping timeout: 180 seconds) 19.04.27 # Torne: Then just "memmove()" the lcd framebuffer... If you choose a font that is 8 pixels high, that will also be easy on mono/greyscale targets with vertically packed pixels. 19.04.29 # that will break games that expect unbuffered output but i can't see it being fast enough otherwise 19.04.45 # Torne: if it's full width and height, you could advance the framebuffer with an relatively simple trick 19.04.49 # linuxstb: scroll region is an arbitrary rectangle 19.04.55 # measured in character cells admittedly 19.04.56 # but still. 19.04.59 # and it's using sysfont atm ;) 19.05.24 # so yah. one way to do this would be to scroll in the framebuffer 19.05.35 # i still need to buffer the text though, so i can redraw the screen after going to a menu 19.05.46 # at that point a 0.15s redraw time is fine because that only has to be *once* :) 19.05.51 # something like frame_buffer = framebuffer + LCD_WIDTH*LCD_HEIGHT*sizeof(fb_data) 19.06.15 # kugel: it's any arbitrary region, but yes, i could do it by blitting 19.06.25 # hm no, that probably wouldn't work 19.06.40 # but it's probably in reality much easier to just be lazy about updating the screen 19.06.51 # at the cost of breaking games that expect to be able to output hwile they are processing. 19.07.14 # the dumbfrotz that i started with does that anyway :) i just assumed it'd be fast enugh not to have to bother 19.07.22 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 19.08.09 # * Torne also wonders if the effort of searching the text buffer for consecutive runs of characters formatted the same would be worth it in the reduced number of calls to lcd_putsxy 19.08.10 # Nothing on the ipod video is "fast enough"... 19.08.34 # 0.15s is fast enough to get your screen back after going into a menu when you're playing a text adventure :) 19.08.44 # and i can make it a bit better in the average case by, say 19.08.47 # linuxstb: The cleanup you mentioned is in FS#10366 . Thanks. 19.08.48 # not printing trailing whitespace 19.09.00 # (or in fact any whitespace at all since i cleared the screen anyway) 19.09.21 # kugel: The sound.c file is being left alone. Thanks also. 19.10.50 Quit Jaykay ("ChatZilla 0.9.84 [Firefox 3.0.11/2009060215]") 19.16.57 # Torne: indeed. First do the trivial optimisations and then see how bad it is :) 19.19.08 Join Hillshum [0] (i=cd7ae838@gateway/web/freenode/x-bda0a5972bb654fb) 19.20.34 Quit Ubuntuxer (Read error: 110 (Connection timed out)) 19.21.09 Quit Lss (Read error: 104 (Connection reset by peer)) 19.22.48 Join Blue_Dude_ [0] (n=chatzill@64.25.25.6) 19.24.01 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 19.25.39 Join Blue_Dude__ [0] (n=chatzill@adsl-235-206-197.mco.bellsouth.net) 19.33.43 Quit n1s (Read error: 60 (Operation timed out)) 19.35.25 Join __lifeless [0] (n=lifeless@188.16.102.157) 19.37.41 # New commit by 03rasher (r21464): Center the list on the currently loaded file in the following screens (FS#10093): ... 19.41.32 Quit Blue_Dude (Read error: 110 (Connection timed out)) 19.44.20 Quit Blue_Dude_ (Read error: 110 (Connection timed out)) 19.47.21 Join tessarakt [0] (n=jens@e180070088.adsl.alicedsl.de) 19.50.43 Quit _lifeless (Read error: 110 (Connection timed out)) 19.51.08 Join JdGordon| [0] (i=836b0049@gateway/web/freenode/x-649228b02ed1420e) 19.52.55 Quit domonoky ("Leaving.") 19.53.42 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 19.56.04 # rasher: "While Playing Screen" is maybe not a good idea 19.56.13 # kugel: Oh? 19.56.32 # I'd think it leads to that screen, instead of chosing a file which "formats" it 19.56.45 # You're inside "theme settings"? 19.57.17 # yea, you changed "Browse .wps files" to "While Playing Screen" 19.57.23 # I don't have a better idea though 19.57.43 # I know. I just think it makes perfect sense, when you consider that it's "Theme settings > While Playing Screen" 19.58.14 Join ZincAlloy [0] (n=d9eec620@gateway/web/cgi-irc/labb.contactor.se/x-8da0da5ba5922a51) 19.58.16 # we will see 19.58.32 Nick J-23 is now known as zajeliminicka (n=zelazko@unix.net.pl) 19.58.42 Nick zajeliminicka is now known as J-23 (n=zelazko@unix.net.pl) 19.59.18 # Hi everybody. Is anybody else experiencing freezes when selecting files in the browser while rockbox is automatically changing directories? 20.00.04 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.00.30 Join kugel_ [0] (n=kugel@e178104221.adsl.alicedsl.de) 20.00.40 Quit kugel (Nick collision from services.) 20.00.44 Nick kugel_ is now known as kugel (n=kugel@e178104221.adsl.alicedsl.de) 20.01.47 Join Hendrik_ [0] (n=chatzill@xdsl-84-44-178-147.netcologne.de) 20.06.12 # New commit by 03rob (r21465): TCC78x: Make the NAND driver yield during reads (thanks to bertrik for spotting the obvious error that caused this to crash until now). Fixes the D2 ... 20.11.34 Quit HellDragon (Read error: 104 (Connection reset by peer)) 20.11.48 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 20.12.19 # meh 20.12.39 # shotofads not here 20.13.37 Join BryanJacobs [0] (n=bryanjac@e33.cs.rochester.edu) 20.14.40 # kugel: IIRC he's been quite swamped with a lot of real-life stuff and doesn't get much of a chance to do any Rockbox-related work. 20.14.42 Join merbanan [0] (n=banan@c-83-233-243-100.cust.bredband2.com) 20.14.54 # LambdaCalculus37: he just committed something ;) 20.15.13 Join derbaron [0] (n=4d17da67@gateway/web/cgi-irc/labb.contactor.se/x-1ab78cdfe6070e41) 20.15.22 # kugel: Maybe he just got a little free time? ;) 20.18.04 # New commit by 03rasher (r21466): Make sure pwd is the same dir that holds runclient.sh and rbclient.pl. 20.18.07 # kugel, while playing with your fuze a bit at devcon, I noticed that the blue bar was not always the exact same colour, it seemed to depend on buttons too 20.18.07 # LambdaCalculus37: it seems ;) 20.18.17 # huh 20.18.23 # I didn't notice that 20.18.39 # I think I saw it in the debug/frequency screen 20.18.59 # increase the frequency to bring up the blue bars then press some buttons 20.19.08 # will try 20.19.13 # at least that's what I remember 20.19.17 Quit lucent (Read error: 104 (Connection reset by peer)) 20.22.56 Quit derbaron ("CGI:IRC") 20.22.58 Join petur [0] (n=peter@d54C6F58E.access.telenet.be) 20.23.07 Quit Blue_Dude__ ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 20.24.24 # BryanJacobs: Hi, how are things going? 20.25.22 # linuxstb: A-OK 20.25.38 # I'm finishing up multi-file buffering 20.25.49 # going to worry about reducing back-and-forth seeking later 20.25.55 # you saw my last status update email? 20.26.19 # Yes. Can you explain how your multi-file buffering works? 20.26.32 # the way I'm building it currently is as follows: 20.26.45 # Is this with the actual Rockbox buffering code? 20.26.50 # ? 20.26.56 Quit flydutch ("/* empty */") 20.27.00 # it's never good when the first step is a question mark 20.27.09 # define "actual" - I'm editing the latest Rockbox SVN with the goal of making it work on target 20.27.15 # Mikachu: :-P 20.27.27 # the "?" was in response to linuxstb's question 20.27.29 # BryanJacobs: I mean is this something you've integrated into Rockbox, or is it a standalone test at the moment? 20.27.47 # linuxstb: it's not done yet but it should work on target when I finish 20.27.57 # now, how I plan to have it work: 20.28.13 # first, note that I'm not going to obsolete the current buffering methods 20.28.13 Join einhirn [0] (n=Miranda@p4FC61575.dip0.t-ipconnect.de) 20.28.14 Quit JdGordon| (Ping timeout: 180 seconds) 20.28.21 # they'll remain available for all codecs to use 20.28.34 # but, when a codec wants multi-file buffering it can make a secondary set of calls instead 20.28.36 Quit einhirn (Client Quit) 20.28.48 # first, it calls request_buffer multiple times - once per file it wants buffered 20.29.22 # then, it calls inform_consumed to tell the buffering layer to advance the buffer (like the advance_buffer call we had before) 20.30.09 # when it reaches the end of a buffer prematurely it calls block_on_buffer to sleep on filling 20.30.29 # that's the entire API, three calls 20.30.37 # plus a free makes four I suppose 20.30.46 # Hmm, what do you mean by "when a codec wants"? The codec itself is loaded after buffering has happened. 20.31.12 # the way I envisioned it is that the codec is loaded after the "primary" file is buffered but before the secondary one 20.31.17 # or tertiary etc 20.31.28 # so would you throw away other cached primary files then? 20.31.30 # the codec needs to look at the header to determine if another file is needed, in the case of wavpack 20.31.44 # At that time, another codec may be running, decoding an earlier file. 20.32.12 # linuxstb: as long as there's some buffer space remaining there shouldn't be an issue 20.32.20 # if the buffer is full we need to wait for the other codec to free some 20.32.22 # Before the file is buffered, the "get_metadata()" function (in core Rockbox, not part of the loadable codec) is called. This parses the file, and can tell if it's a hybrid file. 20.32.42 # BryanJacobs: what if there are four files in the buffer, first is wavpack, the other 3 are mp3, and it is full, what happens? 20.32.42 # I suppose it would be a good idea to hook in there instead of inside the codec 20.32.58 # Mikachu: we'd have to use the wavpack space >_< 20.33.19 # I was kind of viewing the buffer as "mine" to steal when the wavpack codec is loaded 20.33.22 # maybe that's a mistake 20.33.33 # BryanJacobs: Yes, I think so. That function reads data from the disk directly - there's no buffering API in the middle. So it can do what it wants, and read whatever it wants. 20.33.49 # i.e. it uses the standard open() and read() functions. 20.33.53 # I see that 20.34.09 # maybe we should try making the buffer a linked list of blocks 20.34.27 # with each codec calling a function to get "its own" next block 20.34.37 # which returns a size as well as a pointer 20.35.21 # like, struct { void* curptr, unsigned size } get_some_more_of_my_stuff(void* prevptr) 20.35.39 Join JdGordon| [0] (n=836b0049@gateway/web/cgi-irc/labb.contactor.se/x-c3936374f813c6db) 20.35.43 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 20.35.58 # then a single codec can handle two files by holding onto two prevptrs at once 20.36.01 Quit JdGordon| (Client Quit) 20.36.07 # does that sound good? 20.36.45 Join einhirn [0] (n=Miranda@p4FC61575.dip0.t-ipconnect.de) 20.38.49 Quit BryanJacobs ("Java user signed off") 20.39.00 Join BryanJacobs [0] (n=bryanjac@e33.cs.rochester.edu) 20.39.05 # I'm not sure I understand - what does a block contain? 20.39.17 # a block is some binary data loaded from the disk 20.39.33 # whatever has been read into the buffer 20.40.01 # the important logical change is that instead of storing the buffer as a straight ring, it's a set of linked lists 20.40.03 # So how does that help? The main problems that I can see are that you need to read from two files, which may not fit completely inside the buffer. 20.40.25 # they don't have to so long as we can give some of each file to the codec 20.40.52 # New commit by 03kugel (r21467): Redo r21460 and r21462 so that it doesn't introduce a new #define. Patch by Jeffrey Goode, taken from FS#10366. 20.40.55 # buffer 50/50 at first and then perhaps an adaptive algorithm later 20.41.14 # or we can give a hint when we open the file about how much to read at once 20.41.26 # so, if there's only one file in the buffer it looks like this: 20.41.36 # FILE1 chunk -> FILE1 chunk -> FILE1 chunk 20.41.42 # if there are two it looks like this: 20.41.46 Quit kugel (Read error: 110 (Connection timed out)) 20.42.13 # FILE1 chunk -(ptr to slot 3), FILE2 chunk -(ptr to slot 4), FILE1 chunk, FILE2 chunk 20.43.01 # it's like a malloc() implementation, kind of 20.43.26 # it's exactly like a malloc implementatoin, really ) 20.43.30 # Isn't that going to result in 1) holes in the buffer; 2) the data not being contiguous? 20.43.38 # yes to both 20.43.45 # so did we solve the problem of identifying the file before the codec is opened? 20.43.49 # the holes are free spots available for further buffering 20.44.10 # Mikachu: the file identification isn't the problem, it's just that after the codec is opened it can ask for additional files 20.44.26 # for example, album art files named in APE tags or some such 20.44.26 # so you're going to always reserve some empty buffer space in case a codec needs another file? 20.44.35 # isn't this going to cause some disk seek every time you play a hybrid file? 20.44.47 # Mikachu: yes, how could that be avoided? 20.44.50 # because you don't know which secondary file you need until it already started playing 20.44.58 # BryanJacobs: that was what i was asking i guess :) 20.45.11 # we either have to waste disk time opening a correction file we don't need, or we have to spin up when we load the file 20.45.16 # file format aware buffering code 20.45.20 # either way we could end up losing 20.45.42 # Mikachu: could still be wrong if a correction file is present but mismatched/unneeded 20.45.46 *** Saving seen data "./dancer.seen" 20.46.05 # The get_metadata() function should be able to work all that out. 20.46.06 # couldn't you just put the code that determines if it is unneeded in the bufferer instead of the codec? 20.46.26 # linuxstb: get_metadata can't read the correction file, so if the .wvc is wrong/broken it won't know 20.46.32 # example: 20.46.40 # Why can't it read it? 20.46.43 # surely you're not optimising for the case where files are wrong/broken though 20.46.59 # as long as the system doesn't totally fall over when that happens it's fine, no? :) 20.47.06 # Torne: yeah, I suppose so 20.47.06 Quit Cory` ("There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence.") 20.47.16 # ok, so we read both files at metadata time 20.47.28 # and compare headers/make sure they match 20.47.32 # right? 20.47.52 # BryanJacobs: You can if it's needed. Although maybe we'll decide that just checking a file exists is enough of a check. 20.47.54 # i was implying you could just assume they will match 20.48.07 # and if at playback time it turns out not to just throw it away 20.48.10 # why is a broken correction file more serious than a broken primary file? :) 20.48.13 # and take the performance hit of having buffered something useless 20.48.27 # OK, deal, we say "silly users, name your files correctly" 20.48.30 # (except that it takes up more buffer space) 20.48.40 # as long as it doesn't actually *crash* who cares. silly users. :) 20.48.47 # so then we do need file-format-aware buffering code 20.48.53 # i think you have to be a pretty advanced user to use these hybrid files in the first place, right? 20.49.03 Join Cory` [0] (n=Cory@h86.179.89.75.dynamic.ip.windstream.net) 20.49.04 # because otherwise we can't determine which secondary file(s) are needed 20.49.17 # how else do we know to add 'c' to the filename to find the correction file? 20.49.25 Join KBH [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 20.49.26 # BryanJacobs: no, you just need some way for get_metadata to communicate this fact to eh buffering code 20.49.39 # get_metadata gets called for the primary file, it can do what it likes, go look for the secondary one 20.49.40 Quit martian67 (Read error: 60 (Operation timed out)) 20.49.41 # is get_metadata a function in the codec? 20.49.42 # BryanJacobs: Yes, that's how I always thought your project would go - making the buffering code aware that there's a second file to buffer, and maybe even using wavpack-specific buffering code. 20.49.50 # get_metadata says buffer_get(primary_file+"c")? 20.49.55 # Mikachu: no, it's in core 20.49.58 # okay 20.50.03 # Although there's an obvious downside to that approach (wasted code in the core for 99% of users) 20.50.12 # Mikachu: but it's implemented seperately for each container format 20.50.25 Join martian67 [0] (n=xP@2001:470:b:356:221:91ff:fe8c:d8a7) 20.50.32 # linuxstb: the way I interpreted the attitude of the developers at my interview, I thought the goal was to produce something as generic as possible 20.50.43 # they, generalized multi-file buffering instead of codec-specific code 20.50.47 # *thus 20.51.02 # I have no objection to doing it either way 20.51.09 # but with the other approach, the file isn't buffered at all, if i got you right 20.51.23 # the whole point of buffering is to avoid spinups for as long as possible (i think) 20.51.33 # * Torne would think the buffering stuff should just be general, and get_metadata should handle asking for the generic buffer stuff to do the extra files. 20.51.37 # My impression was that we want a general framework, with an implementation specific to wavpack hybrid. i.e. make it easier for others to do the same for other formats. But yes, I think we need the input of other devs before going too far down a particular road. 20.52.07 # I like the idea of changing buffering to behave like malloc 20.52.17 # New commit by 03pondlife (r21468): Allow use of timestretch with semitones in the pitchscreen. Rename variables to clarify the meaning of 'speed'. 20.52.19 Join HBK- [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 20.52.19 # BryanJacobs: other people are unlikely to, probably :) 20.52.20 # is there a particular downside to having noncontiguous regions? 20.52.24 # at least descrbed like that 20.53.04 # I mean, you go codec(region_1), reg2 = next_region(region_1), codec(reg2), reg3 = next_region(reg2), ... 20.53.11 # is the overhead really that bad? 20.53.25 # in nice cases, probably not 20.53.28 # BryanJacobs: Yes, codecs expect their data to be contiguous. Or at least, to receive small chunks of contiguous data. 20.53.44 # they would be receiving small chunks of contiguous data 20.53.51 # cant we just make a codec specific loading function ? so those two files are treated as one (maybe with interleaving) ? 20.54.02 # BryanJacobs: but they might have opinions on the alignment/etc of that data? 20.54.06 # domonoky: yes, but that's almost useless to other codecs 20.54.16 # BryanJacobs: they may want, say, whole frames 20.54.22 # Torne: malign is like an aligned malloc :-P 20.54.24 Quit HBK (Read error: 60 (Operation timed out)) 20.54.29 # or you could set a minimum chunk size 20.54.32 # BryanJacobs: i mean with respect to the data in the input file 20.54.36 # not the locatin in memory 20.54.40 # i like how bad the word "malign" is for that function 20.54.41 # BryanJacobs: why, other codecs could do the same, metadata.c registering a codec specific loading callback. 20.54.46 # they might want to only read entire frames 20.54.53 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 20.54.56 # as contiguous regions 20.55.00 # where the frame size is variable ) 20.55.01 # The codec API guarantees that the get_buffer() function returns a pointer to the next 32KB of data. The only time this function requires a memcpy currently is at the buffer wraparound point (i.e. once every 29MB or so on most targets). 20.55.07 # domonoky: but you can't call codec specific code if the codec isn't loaded 20.55.36 # linuxstb: so why not always make it at most 32KB worth of data? 20.55.36 # Mikachu: it ofcouse has to stay in the metadata code, to be available at loading time. 20.55.41 # right okay 20.55.41 # then we don't have real malloc issues 20.55.48 # we just divide the buffer into 32KB chunks 20.55.55 # and chain together chunks as we like 20.56.03 # overhead: one function call per 32K of data decoded 20.56.14 # BryanJacobs: Because a codec may only use 24KB of it, then it expects the next request to contain the final 8KB of that data, plus the next 24KB. 20.56.32 # linuxstb: hmm. 20.56.37 # how often does that happen? 20.56.39 # BryanJacobs: the entire api is set up as "it's a ring buffer", basically :) 20.56.47 # BryanJacobs: All the time in most codecs. 20.56.48 # if the next chunk is free, we don't have to memcpy 20.56.51 # 20.57.10 # ok, that sounds bad - we have to copy the 8k into a new chunk iff the next chunk is in use 20.57.11 # i.e. lots of codecs don't know the size of the frame until after it's been decoded. But they know it's no bigger than 32KB. 20.57.24 # what other rockbox targets have an actual speaker onboard? 20.57.26 # BryanJacobs: yah. so then fragmentatin starts to become very expensive 20.57.37 # * domonoky still thinks a codec specific loading function is the way to go, to not spend the whole summer on buffering issues :-) 20.57.44 # I feel I might have been to ambitious 20.57.47 # *too 20.57.56 # domonoky: interleaving/etc only works if you know the relative rate at which you will consume the files 20.58.13 # domonoky: if you might end up using up most of file A and only using a bit of file B, but don't kow that ahead of time, interleaving doesn't work 20.58.13 # i assume both files are variable bitrate too? 20.58.25 # Mikachu: yes 20.58.47 # well, you don't know the number of bits/frame 20.59.07 # but you do know bits/block after you read the block header 20.59.09 # am i also right in assuming the whole correction file won't fit in the buffer on most targets? 20.59.21 # the correction file can be 3x the lossy 20.59.22 # in size 20.59.35 # so, no, that's not a good approach 20.59.38 # well, it trivially won't since songs can be any length :) 20.59.51 # Mikachu: assume 74-minute prog rock odyssey :) 20.59.59 # you should never trust that a file fits in memory.. we have targets with small buffers :-) 21.00.01 # my point is that if you interleave, you have to do it exactly, otherwise you will overwrite yourself when you wrap around 21.00.22 # ooh, that's a thought 21.00.27 # if you are imagining what i think you are 21.00.27 # not necessarily - there are internal 1k buffers in the wavpack codec 21.00.48 # interleave the files in such a fashion that you effectively have two entire interleaved ring buffers 21.00.57 # sorry all, I've g2g, I'll be back in 30 mins - 1 hour 21.01.07 # Torne: isn't that kind of like what I was describing? 21.01.13 # two linked lists occupying the same space? 21.01.21 # bbl 21.01.21 # BryanJacobs: no, i'm talking about having an entirely fixed arrangement 21.01.26 # not a linked list 21.01.38 # and with no possibility to free it in holes. 21.01.42 # if so, wouldn't it be better to have the ring buffers be separate areas, instead of interleaved? 21.01.46 # a möbius buffer? 21.02.24 # Mikachu: well, you could.. i don't know that that mixes with single-file use though? 21.02.30 Quit HBK (Read error: 60 (Operation timed out)) 21.02.36 # this is just a wild thought i'm having, not a fully considered solution :) 21.02.41 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 21.02.48 # bertrik: The connect has a speaker if you fancing doing the port :) 21.02.50 # it sounds like permanent interleaving would mess with them much more 21.03.00 # not permanent, just while buffering that file 21.03.05 # ah 21.03.20 # so if the whole thing fits in the buffer then it's the same as loading one then the other from everyone else's POV 21.03.28 # AlexP, the connect looks like too much work to port I think 21.03.32 # and if not then eventually you wrap around and the entire buffer contains interleaved bits of the thing you are buffering 21.03.42 # bertrik: Ye of little faith :) 21.03.55 # until you've buffered up to the end of both files, at which point you start using wherever the later buffer finishes as the single ring buffer again for the next file 21.03.59 # i'm not sure that makes sense ) 21.04.06 # or is any better tahn any other way of doing it 21.04.25 # Torne: the problem i meant earlier was you have a buffer of 5 MB, you load 1MB primary file and 4MB secondary file, and when you reach the end, you still have 200kB unused primary file, but you can't continue reading the secondary one 21.04.44 # so that would be solved with your permanent pattern 21.04.47 # yah, so you read them in 128kb chunks interleaved 21.04.59 # then if you've run out of one file you just refill the alternate blocks 21.05.05 # and leave the other file's bits alone 21.05.08 # well, the ratio would be up for debate 21.05.16 # well yah. it would have to be static though 21.05.22 # so get_metadata would have to propose a suitable one 21.05.35 # but yah the point is to not try and free buffers as you go along, more or less 21.05.43 # but i guess when you're listening to lossless you don't expect no spinups anyway (double negation intended) 21.05.46 # you may have to live with bad choices of ratio 21.06.13 # but the thing in my imagination here at least wouldn't itnerfere with the subsequent files to be buffered 21.06.33 # it'd be a reasonable distance from making optimal use of the available buffer space, though 21.07.16 # ...hm 21.07.25 Quit KBH (Connection timed out) 21.07.25 # yeah it doesn't actually matter if you interleave or not then 21.07.38 # oh, no, wait. 21.07.46 # if you already have the previous tracks buffered it does. 21.07.54 # say, half the buffer is full of mp3 21.08.08 # you can't just divide the other half of the buffer up, because then you'd be wasting the rest of ram once the mp3s are played 21.08.11 # so interleaving does help 21.08.14 # if you don't interleave, you would get my two circular buffers instead 21.08.27 # yah. but that only works as well if ram is empty to start with 21.08.29 # which it usually won't be 21.08.45 # interleaving means you can buffer 'a bit more' later and take yup the space that wasn't free before. 21.08.54 # yeah 21.09.09 # so, yah, i *think* it works 21.09.19 # it's not going to be optimal for buffering the multi-file track 21.09.26 # unless your guessed ratio is spot on 21.09.38 # but i think youc an do it without interfering with the previous/next thing in the buffer.. 21.09.49 # maybe you could (ab)use the tag cache or dircache to store optimal ratios for files? 21.09.55 # The ratio can be guessed by the size of the two files - I would expect that would be quite close. 21.10.00 # linuxstb: probably 21.10.20 # yeah, optimally you would reach the end of both files at the same time :) 21.10.34 # well you would reach the end at the same tim in almost all cases 21.10.38 Quit HBK- (Connection timed out) 21.10.42 # unles the codec is very weird :) 21.10.51 # but you may get out of sync inbetween 0 21.11.08 # yeah, but if you get out of sync in between and change the ratio, you will be out of sync at the end instead 21.11.26 # i wasn't imagining you'd ever change the ratio once you started buffering the track 21.11.38 # keep it static and the buffering code doesn't need to be *too* complicated 21.11.51 # no i didn't mean dynamically 21.11.54 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-fffd703f7b946277) 21.11.54 # of course the codec using this would have to not expect the restriction linuxstb explained above 21.12.02 # rather, the same files with another ratio, you would be out of sync at the end 21.12.07 # it would have to be happy with getting back noncontiguous data ;) 21.12.26 # but say for things like .psf files that have a .psflib, it would be a different matter 21.12.33 Join _Auron_ [0] (n=DarkAuro@adsl-76-203-192-240.dsl.rcsntx.sbcglobal.net) 21.12.42 # i don't know anything about any of these codecs, admittedly ) 21.12.46 # no idea what wavpack is 21.12.50 # it's more like a midi file and patchset i think 21.13.15 # (the .psf ones - playstation music) 21.13.21 Join Ashex [0] (n=Ashex@c-98-247-101-203.hsd1.wa.comcast.net) 21.13.26 # wavpack is a lossy/lossless codec (you probably got this part already :) 21.13.26 # ah 21.13.32 # yeah i inferred as much 21.13.40 # Why is it that the Utility makes all directories read only when I try to install a theme? 21.13.44 # patchset type formats are a totally different problem to buffer 21.13.55 # unless the entire patchset fits in ram you are basically stuffed 21.14.02 # yeah 21.16.25 Quit ZincAlloy ("CGI:IRC (EOF)") 21.16.41 # The other buffering issue we have are large non-streaming formats like MOD, where the codec needs constant random access to the entire file. 21.16.52 Quit Hillshum (Ping timeout: 180 seconds) 21.17.05 # yah, that's just the worst case of patchset type buffering 21.17.07 # that is basically the same issue as the patchset ones then 21.17.14 # where the random-access bit is 100% of the file instead of a smaller percent :) 21.17.15 # It's a bit annoying. I've got a udev rule that automounts a usb device rw and rockbox makes the directories read only and complains that it can't install a theme 21.17.46 # Ashex: rockbox doesn't make anything read only 21.18.16 # gevaerts, I meant the utility 21.18.55 # Ashex: that shouldn't do that either. Check your dmesg output for related messages. You may have a corrupted filesystem 21.19.37 Join funman [0] (n=fun@rockbox/developer/funman) 21.23.27 # * linuxstb wonders if anyone is working on mp3-hd - mp3 with a lossless correction file stored in an id3v2 tag... 21.23.43 # I mean working on reverse-engineering mp3-hd... 21.24.11 # linuxstb: how spread is mp3-hd ? (never heard about it) 21.24.20 # gevaerts, yep. looks like fs corruptions 21.24.55 # funman: It's relatively new - I would be surprised if it catches on... 21.26.20 # didn't fraunhofer do something like that before with mp3pro? 21.27.09 # though not lossless, just 'better' 21.27.13 # they did 21.27.22 # mp3 with sbr 21.27.43 # and nobody on earth cared because it was proprietary and nothing played it? :) 21.27.45 # merbanan: Do you know of anyone showing any interest in mp3-hd? Isn't it based on some AAC+correction file format? 21.28.34 # no idea 21.29.01 # fraunhofer for sure 21.29.42 # what is the actual use case for these formats? Is it just to be backward compatible with your crappy player without having to transcode? 21.30.00 # or is there some other benefit i'm missing? :) 21.30.35 Join krazykit` [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 21.32.27 Quit CaptainKwel (Remote closed the connection) 21.32.27 Quit saratoga (Remote closed the connection) 21.32.27 Quit LambdaCalculus37 (Remote closed the connection) 21.32.27 Quit evilnick (Remote closed the connection) 21.33.43 Join kugel [0] (n=kugel@rockbox/developer/kugel) 21.35.15 Quit lilltiger (Read error: 54 (Connection reset by peer)) 21.35.44 Quit krazykit (Read error: 110 (Connection timed out)) 21.37.36 Join CaptainKwel [0] (i=2669ecc2@gateway/web/freenode/x-83a2a74433a6938e) 21.37.37 Join LambdaCalculus37 [0] (i=44a0430d@gateway/web/freenode/x-c164b29e5d0f59d6) 21.38.49 Join lilltiger [0] (n=lilltige@82.145.152.217) 21.43.19 # I'm trying to write recording support for Sansa AMS but the recording thread deadlocks when I start recording :/ 21.43.36 Join Hillshum [0] (i=cd7ae838@gateway/web/freenode/x-820713fd56ad7d36) 21.44.23 # i am not sure if the problem is in my code since i don't see any ams-specific functions being called except pcm_rec_dma_get_peak_buffer() 21.46.13 # New commit by 03bertrik (r21469): Meizu lcd-m3: whitespace fixes 21.46.36 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-654a7803949b6a3a) 21.51.08 # New commit by 03pondlife (r21470): Oops. 21.52.49 Quit Unhelpful ("ZNC by prozac - http://znc.sourceforge.net") 21.56.14 Join Unhelpful [0] (n=Militant@rockbox/developer/Unhelpful) 21.56.37 Join Rondom [0] (n=Rondom@dslb-084-057-175-182.pools.arcor-ip.net) 21.57.11 Join jgsprenger [0] (n=63e9625a@gateway/web/cgi-irc/labb.contactor.se/x-3d8b244951d1726f) 21.58.41 # bertrik: any idea why shotofads decided for USEC_TIMER, and not plain ticks like AMSes do, that way tcc77x wouldn't be excluded 21.58.51 # ? 21.59.08 Quit LambdaCalculus37 () 22.00.31 Quit jgsprenger (Client Quit) 22.01.31 Join markun [50] (n=markun@rockbox/developer/markun) 22.03.19 # kugel, no I don't know, but what do you mean by plain ticks? 22.03.43 # I think the idea is not to wait, but to make sure it does a yield once every milisecond 22.03.49 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 22.04.16 # kugel: the answer is simple the AMS Sansa ports didn't exist when I first wrote that code ;) 22.04.51 # I'd been trying to get yielding to work in that driver for quite some time 22.06.31 Quit petur ("Zzzzz") 22.11.48 Join ender [0] (i=krneki@foo.eternallybored.org) 22.13.44 Quit Hillshum ("Page closed") 22.14.11 # I should probably commit the meizu pwm backlight stuff 22.15.04 Join heftig [0] (i=jan@2a01:198:3f6:0:21f:3bff:fe53:b08b) 22.16.46 Quit ender` (Read error: 110 (Connection timed out)) 22.17.32 Join fml [0] (n=4fd3e2fc@gateway/web/cgi-irc/labb.contactor.se/x-8c558161e301fb50) 22.19.06 Join Chesteta [0] (n=Chesteta@67.148.163.64) 22.19.27 # hello, does anyone know when the disk corruption issues began for the ams devices? 22.19.59 Join BeChris [0] (i=5c89760a@gateway/web/freenode/x-95a69a6467b0291b) 22.20.40 # if there's anyone, it's probably funman who knows 22.20.51 # Hello everybody 22.20.53 # I noticed some problems when I tried patch 10344 however there were other patches applied also (I 'added' that one to the other applied patches) and noticed I could not see my SD card 22.21.12 # but I think it's only getting better as time goes on, not worse 22.21.13 # Can FS#5080 be closed now that r21464 has been committed? 22.21.37 # then I was gone for the weekend and when I came back and there was posting about disk issues 22.24.41 # oh, so the disk issues have been there all along? (there is no 'new' issue that makes things 'more likely' to be messed up?) 22.24.57 # I think patch 10344 is a nice experiment, but has possible stability issues 22.25.00 # fml: I guess so, although it doesn't do what 5080 wanted - highlighting the theme... 22.25.24 Quit goffa_ (Read error: 60 (Operation timed out)) 22.25.30 # Chesteta: it began when fs#10048 was committed 22.25.40 # ok, thank you 22.25.50 # bertrik: why stability ? 22.26.48 # linuxstb: is it in principle possible to highlight a theme? Is it stored at all? 22.26.52 # the datasheet mentions 1.1V but the patch uses 1.05V. Also some time might be needed between switching back to full voltage and boosting. 22.27.37 # you mean after modifying the voltage by I2C ? 22.27.41 # fml: It's not stored, no. We'd need to store themes when they are selected, which could prove difficult to do reliably 22.28.03 # perhaps saratoga could do measurements and comment on FS#10344 22.28.04 Join goffa_ [0] (n=goffa@216.220.23.105) 22.28.47 # rasher: that's what I thought (that he theme is not stored). All the settings from the theme are loaded, but the name of the theme file is not saved. So I'll close FS#5080. 22.29.17 # shotofadds: oh you had that fix locally for some time already? 22.29.20 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 22.29.25 # funman, if you missed my comment earlier; my e280v2 did not see my sd card when I applied 10344 *however* i had other patches applied too so its just something to look into, not necessarily a problem 22.30.24 # fml: Well we could try to store the name of the theme, but it's not possible to do in the same easy way as the other settings 22.30.29 # Chesteta: i don't want to know about any bug report for storage driver 22.30.30 # fml: I'm fine with closing it 22.30.55 # ok, understood 22.30.56 # I already know that it doesn't work, and that the problems randomly appear/disappear 22.31.14 # so I think precise bug reports won't help finding the exact cause 22.31.16 # Please, I need some help concerning my png plugin 22.31.33 # kugel: yeah, but it was causing a crash until bertrik's fix (the mutex wasn't being initialized properly) 22.31.35 # rasher: IMO it would be easy to store the theme name. The problem is that once you manually change e.g. the font you no more have that theme. 22.32.29 # fml, linuxstb: the problem with theme files is that it's just a collection of settings. Change one theme setting and it's technically not the theme anymore. Change more and you totally obfuscate it so that it wouldn't make any sense to still select it. There's no reliable way I think 22.32.54 # shotofadds: Ah, I see. I think with using the normal tick the tcc77x could also be fixed 22.33.04 Join faemir [0] (n=faemir@78.33.109.163) 22.33.10 # kugel: exactly what I said 22.33.39 # although I'm not sure why we've chosen 5ticks 22.33.52 # i was going to ask about 5 ticks vs. 1000us 22.34.24 # I think the best thing is to implement the proper timer on 77x and then they can both use the existing method 22.34.32 Quit domonoky (Read error: 104 (Connection reset by peer)) 22.34.33 # well, given that 1000us should be 1ms, 5 ticks are 50 times of that 22.34.59 # probably randomly choosed 22.35.27 # shotofadds: I'm actually not sure if ticks might be preferable or not 22.35.50 # where are these 5 ticks you speak of? 22.35.59 # i have not seen latency problems with the ams SD driver 22.36.07 # bertrik: delay before yielding in sd driver 22.36.58 # not "delay before yielding", rather "period between yields" 22.37.13 # funman: the problem is that other threads might need to run more often 22.37.34 # for example, the backlight thread runs every 3 ticks while backlight fading 22.37.54 # back 22.38.25 # kugel: ok 22.38.33 # well, every 4 for our targets, but still 22.39.50 # Do we want to have a special WPS token for "skip length" (FS#8965) or is the %St (generic tag for setting values) tag enough? 22.40.08 # I'd like to either commit or reject FS#8965 22.40.11 # probbaly not' 22.40.18 # linuxstb: you still there? 22.40.43 # JdGordon: was your response for me? 22.41.08 Quit BeChris ("Page closed") 22.41.25 Join BeChris [0] (i=5c89760a@gateway/web/freenode/x-4f0fd336e71162b2) 22.42.11 Join perrikwp [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 22.42.38 Quit perrikwp (Read error: 104 (Connection reset by peer)) 22.42.38 # BryanJacobs: Yes 22.42.40 # fml: it was.... I seem to remember a discussion about not adding more tags which would double up... 22.42.44 # can the %St be used conditionally in some kind? 22.42.49 # so.. I think %St would be good enough 22.42.57 Join perrikwp [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 22.43.07 # linuxstb: how about we relax the "always returns 32K contiguous data" restriction? 22.43.23 Quit perrikwp (Read error: 104 (Connection reset by peer)) 22.43.33 # BryanJacobs: That's likely to break a lot of codecs... 22.43.36 # we tell the codecs "and I won't give you a fresh chunk until you're done with the one you want" 22.43.40 # BryanJacobs: that could hurt the performance of a lot of codecs even if they were fixed 22.43.42 Join perrikwp [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 22.43.50 # kugel: the wiki page says that %St can also be used in conditionals 22.44.00 # so just reject 22.44.09 Quit perrikwp (Read error: 104 (Connection reset by peer)) 22.44.09 # well, it only has to be that way for codecs that opt in 22.44.15 # the others could have a ring buffer 22.44.30 # BryanJacobs: did you read my suggestion just after you left? 22.44.37 # yes, that's what gave me the idea 22.44.46 # I just got through reading the discussion up there 22.45.02 # well, yah, if you implemented that then the codecs that want to read from multiple files would have to be willing to take the data in the interleaved form 22.45.11 # but other codecs wouldn't have to change 22.45.26 # you said "you'd be wasting the rest of the ram once the mp3s are played" 22.45.29 # but that's not accurate 22.45.34 # hm? 22.45.38 # because as the mp3s are played you can start buffering into that space 22.45.48 *** Saving seen data "./dancer.seen" 22.46.01 # nono, i was talking about having the buffers allocated seperately as Mikachu suggested 22.46.05 # ah, ok 22.46.07 # my mistake 22.46.08 # if you itnerleave them then yes you can keep streaming into fresh space 22.46.23 # I don't see a problem with this scheme 22.46.33 # and when you get to the point that you are using the whole of ram for the itnerleaved buffers, you wrap each buffer seperately 22.46.43 Quit Rondom (Remote closed the connection) 22.46.51 # "wrap each buffer separately"? 22.46.57 # Torne: I didn't get how the correction works if the guess turns out wrong 22.47.00 # they don't "wrap" at all 22.47.11 # they do if the files combined are bigger than ram.. 22.47.19 # Zagor: you don't 22.47.30 # ok, what do you do? 22.47.34 # Zagor: if you run out of one file you start buffering more of that file into the space where it was 22.47.37 # Torne: you don't have to store a chunk that's later in the file later in the buffer 22.47.47 # it doesn't have to be linear like that 22.47.53 # the codec just asks for the "next" chunk 22.47.57 # you mean overwrite played parts of the other file 22.48.01 # which could be higher or lower in RAM 22.48.05 # yes, that's what I mean 22.48.16 # yah. but i'm talking about not bothering to keep that level of accounting 22.48.17 # what's "wrapping" by that definition? 22.48.27 # I think it might be beneficial to do so 22.48.28 # exactly like it was a normal ring buffer 22.48.41 # when you get to the end just wrap around ram and start from the beginning 22.48.48 # offset by the stride amount if you aren't the first one :) 22.48.58 # such that you would ventually overwrite your own data, but not the other files's 22.49.04 # but then you have this complicated "if-legacy-stuff-here" logic 22.49.13 # i.e. you literally interpret ram as two ring buffers 22.49.15 Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 22.49.18 # and you can't arbitrarily change the ratio of buffering the files 22.49.20 # which happen to be interleaved on a fixed buffer size 22.49.23 # and you can't buffer more than two files 22.49.25 # hm? 22.49.27 Join perrikwp [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 22.49.30 # sure you can 22.49.34 # just interleave it 3 ways 22.49.37 # or 4 ways 22.49.38 # or whatever. 22.49.45 # and you can do a new ratio/split for each file 22.49.53 # I don't get it; only one file can have the block at buffer address 0 22.49.55 # i don't mean doing this permanently 22.50.01 # oh, I do. 22.50.05 # yah 22.50.10 # that's my *entire point* :) 22.50.20 # you start doing this at the point in teh buffer where the last track ends and you start buffering the multifile track 22.50.32 # and you stop and go back to linear buffering afterward 22.50.35 # but then you could get another "traditional" track after it 22.50.37 # or re-split with different parameters if needed 22.50.43 # yes. so? 22.50.49 # you start from the later of the two buffer ends 22.51.07 # and just ignore the space inbetween until the data has been played to catch up 22.51.11 # i'm not suggesting this is optimal, but it's a minimal amount of accounting 22.51.27 # and it means regular buffering bhaves the same as now 22.51.33 # so there's no effect on codecs that aren't doing this 22.51.40 # I quite like it 22.51.50 # ...I think :) 22.51.58 # if i had a whiteboard it would be easier :0 22.52.07 # ah - I get it 22.52.07 # I'm not sure this is as efficient as arbitrarily chained chunks, though 22.52.07 # and it might be harder to manage 22.52.13 # it's not as efficient, no 22.52.19 # but the point is that it prbably doesn't matter a lot 22.52.28 # I still like the idea of having a chunk-list in the space not being used by the traditional track 22.52.28 # *track(s) 22.52.46 # I think you might be right 22.52.46 # yah. but there are reasons why rockbox traditionally avoids anything remotely malloc-like :0 22.53.12 # you could just reuse any spare bit *in the gap*, actually 22.53.15 # rather than wrapping very strictly 22.53.27 # just use up any played block that's after an unplayed block 22.53.34 # I intuitively tend toward the malloc-like solution but don't care enough to mind doing it the other way 22.53.44 # such that the portion of the buffer you are using is generally as compact as possible 22.53.51 # we'll get one watermark per file. that's sure to cause amusement :-) 22.53.56 # in order to leave the most space to go back to being a regular ring buffer afterwards. 22.54.01 # Zagor: something to test for the build script? I'm currently running my 64bit dual core 22.54.01 # Zagor: ??? 22.54.03 # that's effectively what it's doing 22.54.15 # youare basically just allocating by prioritising keeping allocated blocks near each other 22.54.18 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 22.54.26 # i.e. maximisng size of contiguous free space. 22.54.41 Join uPRiSePoDDeR [0] (n=4454db77@gateway/web/cgi-irc/labb.contactor.se/x-b534f25ce3eb883d) 22.54.43 # yeah, my metric was minimizing total size of free space 22.54.53 # hey whats up 22.54.57 # kugel: maybe. there still seems to be the issue of some build dirs not being removed. 22.54.58 # ie keeping as much stuff buffered as possible 22.55.07 # yes, you can do taht as well 22.55.08 # how yall doin 22.55.09 Quit fml ("CGI:IRC (EOF)") 22.55.12 # while you are playing you want to use all the ram 22.55.21 # but my point is as you approach the end of the file you want the in-use bits to be squished up together 22.55.29 # so you can start buffering the next file linearly 22.55.35 # instead of having to keep doing malloc-like operations 22.55.41 # what makes the 1g so fucking different from the 2g 2 not be decrypted and hackable? 22.55.47 # Torne: agreed. 22.55.58 # so yes. you could still allocate non-lienarly, you are right 22.56.08 # is there really no way, without full decoding, to determine which parts would need to be interleaved? 22.56.09 # BryanJacobs: with interleaved buffers, we have one pointer for each file. and they will not all reach the spinup watermark at the same time. 22.56.09 # but you want to be careful about the algorithm for it :) 22.56.15 # Zagor: ah. 22.56.21 # uPRiSePoDDeR: apple is what made them so different. 22.56.25 # Torne: agreed. 22.56.36 # linuxstb: sound good to you? 22.56.38 # markun, some comments in system-s5l8700.c seem wrong (inconsistent with the datasheet), where do they come from? 22.56.46 # Zagor: I'm not getting a build 22.56.53 # I mean, was this code copied from some other target? 22.57.02 # yeah but 2g is freakin classic now and its so old whyd they make the code so different? 22.57.08 # uPRiSePoDDeR: http://en.wikipedia.org/wiki/IPodLinux#Compatibility 22.57.11 # kugel: no I don't have it running. I haven't figured out what to try yet. 22.57.18 # uPRiSePoDDeR: How should we know? 22.57.26 # will the 2g ever be crackable? 22.57.34 # alright, I guess I can keep it running, and it will just pick it up once you do something? 22.57.37 # presumably so that we can't run non-apple code on it :P 22.57.42 # how should we know :) 22.57.42 # cuzz i'd like 2 stick some porn videos on mine 22.57.47 # kugel: yes 22.57.51 Quit Llorean ("Leaving.") 22.57.54 # uPRiSePoDDeR: it's so old, most people don't care anymore 22.57.58 # great, /me's already loving the new system 22.58.11 # uPRiSePoDDeR: please have a look at the channel guidelines. We do want real words here 22.58.16 # no its so old it SHOULD be crackable it fucking pisses me off 22.58.39 # * BryanJacobs laughs at black-and-white port on a 1G 22.58.43 # *porn 22.58.43 # Zagor: I did a slight modification of runclient.sh - I'd be surprised if it messes something up, but I guess you might want to keep your eyes open 22.58.46 # Zagor: do you have it setup somewhere on the server? 22.58.51 # uPRiSePoDDeR: old does not mean crackable 22.58.58 # you realise we passed the point where properly implemented encryption is unbreakable by classical computers many, may years ago, right? 22.59.10 # so this is a good example of something that could be in the op guidelines for what is kickable 22.59.25 # i know its juss stupid how they made the code so different is that why i paid 712 for my LTD. addition red 1? 22.59.44 # Torne: tell AACS that 22.59.58 # BryanJacobs: no, *don't* tell them. ;) 23.00.02 # "properly implemented" is very hard when you're not restricting people's ability to view their content 23.00.06 # Unhelpful: heh 23.00.08 # BryanJacobs: DRM is never properly implemented ;) 23.00.10 # uPRiSePoDDeR: You're arguing against facts here. There's nothing we can do to change reality. 23.00.20 Quit krazykit` (Read error: 110 (Connection timed out)) 23.00.36 # ight my bad lol 23.00.39 # BryanJacobs: even if AACS had no weaknesses at all people could still dump a new drive every week if they wanted to :) 23.00.53 # it's effort, but it's not ultimately difficult :) 23.01.01 # Torne: actually, look at Nokia's DRM... their applications are RSA signed 23.01.07 # BryanJacobs: i work for nokia:) 23.01.10 # I think they did it pretty solidly 23.01.11 # oh wow 23.01.16 # * BryanJacobs didn't know that 23.01.17 # i'm a security analyst in fact :) 23.01.29 # and i've disassembled a lot of the programs people ahve written to crack the security on S60 23.01.29 # * BryanJacobs feels happy he wasn't dissing Nokia's security 23.01.29 # what is the best texting phone to get from verizon my dad wants 2 switch soon? i know this is random 23.01.33 # and we have a long way to go yet :) 23.01.38 # Is everything signed? (Savegames etc) 23.01.40 # uPRiSePoDDeR, it's offtopic. ask someone else 23.01.44 # er, somewhere else 23.01.56 # k 23.01.59 # Torne: I personally always wondered how those chinese people managed to generate devcerts 23.02.48 # The DRM talk is also going quickly offtopic guys. 23.02.55 # rasher: already moved 23.03.21 # so if its offtopic we cant talk about it? 23.03.30 # That is what off topic means, yes 23.03.44 # doesnt that sound really stupid? 23.03.59 # What, your question? 23.04.07 # zing 23.04.16 # like if u were talkin with friends they wouldnt yell at you cant go offtopic 23.04.27 # This isn't a social channel 23.04.27 # you're not talking with friends 23.04.34 # It is for support and development 23.04.37 # uPRiSePoDDeR: I told you about real words before 23.05.07 # no im afraid you didn't i dont speak NERD aka unsocialize laungage 23.05.12 # uPRiSePoDDeR: this is #rockbox, we are on-topic even with friends 23.05.21 # uPRiSePoDDeR: Please stop now 23.05.45 # lol im really scared 23.06.27 # . 23.06.39 # does this count as understanding the rules and ignoring them? 23.06.45 Mode "#rockbox +o Bagder " by ChanServ (ChanServ@services.) 23.06.50 # can someone just remove it already? :) 23.06.51 Mode "#rockbox +o AlexP " by Bagder (n=daniel@rockbox/developer/bagder) 23.06.56 # was that a mute? 23.06.58 Mode "#rockbox +o rasher " by Bagder (n=daniel@rockbox/developer/bagder) 23.07.04 Mode "#rockbox +o Zagor " by Bagder (n=daniel@rockbox/developer/bagder) 23.07.32 # ^wut does that mean? 23.07.41 Mode "#rockbox +o Horscht " by Bagder (n=daniel@rockbox/developer/bagder) 23.07.47 # That you can be muted, kicked or banned by anyone who is op 23.07.52 # So please behave 23.08.11 # lol i got a warning go ahead and ban me 23.08.33 # I'd rather not, I'd rather you just followed the guidelines 23.08.39 Join n1s [0] (n=n1s@rockbox/developer/n1s) 23.09.06 Quit uPRiSePoDDeR (Excess Flood) 23.09.24 # * BryanJacobs laughs 23.09.33 Join uPRiSePoDDeR [0] (n=4454db77@gateway/web/cgi-irc/labb.contactor.se/x-fa1a78ee8da25fcd) 23.09.53 # lol was that a kick 23.09.56 # a 23.09.57 # s 23.09.59 # f 23.10.10 Kick (#rockbox uPRiSePoDDeR :Bagder) by Bagder!n=daniel@rockbox/developer/bagder 23.10.20 # _that_ was a kick 23.10.33 Quit merbanan (Read error: 110 (Connection timed out)) 23.10.47 # * BryanJacobs laughs harder 23.11.01 Mode "#rockbox +b %*!n=4454db77@* " by rasher (n=rasher@rockbox/developer/rasher) 23.11.42 # I doubt that will work 23.11.50 # it's probably a session identifier or something like that 23.11.55 # no, it's his ip in hex 23.12.01 # i think Bagder knows how his own webirc works :) 23.12.03 # ah :P 23.12.13 # Mikachu: Except that was rasher 23.12.26 # * Bagder grins 23.12.27 # i only looked at the a and er parts 23.12.30 # let me just.... remove that 23.12.34 Mode "#rockbox -o Horscht " by Horscht (n=Horscht2@xbmc/user/horscht) 23.12.42 # it felt kind of akward 23.12.48 # heh 23.12.57 Join perrikwp_ [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 23.13.15 # i think rasher knows how Bagder's webirc works too though 23.13.24 Mode "#rockbox -o AlexP " by ChanServ (ChanServ@services.) 23.14.07 # just for reference, you probably shouldn't make me op, i would have kickbanned him 10 minutes ago :) 23.16.11 # FS#10371 - Recording for Sansa AMS (not working) 23.16.30 Mode "#rockbox +o gevaerts " by ChanServ (ChanServ@services.) 23.16.31 # Mikachu: Noted :) 23.16.35 Mode "#rockbox -o gevaerts " by ChanServ (ChanServ@services.) 23.16.38 Mode "#rockbox -o rasher " by rasher (n=rasher@rockbox/developer/rasher) 23.18.33 Mode "#rockbox +o rasher " by ChanServ (ChanServ@services.) 23.18.44 Mode "#rockbox -b %*!n=4454db77@* " by rasher (n=rasher@rockbox/developer/rasher) 23.18.48 Mode "#rockbox -o rasher " by rasher (n=rasher@rockbox/developer/rasher) 23.20.25 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 23.21.09 Join kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 23.22.31 # is the current_tick sort of guaranteed to start at 0? 23.22.58 # so that I could a tick counter initialize at 0, instead of making it global just to init it with current_tick in another function? 23.23.18 # Bagder: did you see I set up buildmaster.rockbox.org and changed the client for it? 23.23.27 # funman: what do you mean with crashes at 8px font, it actually works with other fonts? 23.23.55 # Zagor: I did, I was just curious if you have (where?) a dedicated server root for it 23.24.07 # with the default font it locks when starting recording, not as soon as entering the screen 23.24.18 Mode "#rockbox -o Zagor " by ChanServ (ChanServ@services.) 23.24.22 # I thought about invoking the server and check a few things 23.24.24 # the "default" font isn't 8px 23.24.24 Mode "#rockbox -o Bagder " by ChanServ (ChanServ@services.) 23.24.35 # (taking it privately) 23.24.41 # kugel: yes 23.25.14 # ah, reading your sentence correctly helps a lot 23.25.20 # weird thing anyway 23.26.04 # yeah i just wanted to point that something weird happens ;) 23.27.50 Join hillshum [0] (n=hillshum@75-165-235-206.slkc.qwest.net) 23.27.52 Quit ender (" NOTICE: Thank you for noticing this new notice. Your noticing it has been noted. And will be reported to the authorities.") 23.28.56 Quit perrikwp (Read error: 110 (Connection timed out)) 23.28.58 # gevaerts: I'm wondering if we could at least go to charging mode if CONFIG_CHARGING is something but HAVE_USB_STACK is undefined 23.29.16 # going to the usb screen is just the worst thing to do actually 23.29.23 # (speaking of AMSes now) 23.29.48 Part BryanJacobs 23.29.53 # myself I wonder why HAVE_USB_STACK is required for rebooting into OF when usb is inserted 23.30.12 # that too 23.30.38 # because you're supposed to implement the usb stack ;) 23.31.01 # Seriouslu though, mostly historical reasons 23.31.02 # it isn't of any use without usb, is it? 23.31.50 # If you want rebooting, I think the only bit of the USB stack you really need is the usb_detect() function 23.32.00 # the historical reason that you did the usb stack a seperate define and implement it earlier on targets so that you can hide the effective binsize usage of USB? =) 23.33.01 # partly, yes :) 23.33.11 # usb detection actually works already 23.33.50 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 23.33.58 Quit BlakeJohnson86 ("Leaving.") 23.35.11 # Bagder / Zagor: Should clients join half way through a run? 23.35.23 # sure 23.35.27 # So if there was one happening, and I started one, it'd join in? 23.35.32 # clients can come and go as they like 23.35.40 # nice 23.35.45 # Bagder / Zagor: what's the (intended) difference between clientname and username? 23.35.47 # yes, a client will get builds immediately if during a build round 23.36.00 Join perrikwp [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 23.36.01 # gevaerts: the user is you, you may run many clients 23.36.03 # * AlexP starts a client 23.36.05 # gevaerts: username is the same for all your machines. clientname is different. 23.36.08 # ok 23.36.27 Quit perrikwp (Read error: 104 (Connection reset by peer)) 23.36.36 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 23.36.48 Join perrikwp [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 23.37.09 # is it plugged in for real now? 23.37.15 Quit perrikwp (Read error: 104 (Connection reset by peer)) 23.37.29 # no, it'll come and go for a while 23.37.34 # FYI: we still have the bug where it sometimes fails to remove the build dir. 23.37.35 Join perrikwp [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 23.38.02 Quit perrikwp (Read error: 104 (Connection reset by peer)) 23.38.22 Join perrikwp [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 23.38.49 Quit perrikwp (Read error: 104 (Connection reset by peer)) 23.38.50 # I don't understand how that happens. it runs "rm -r" on the dir, yet it stays there. Very puzzling. And it's not a permission thing since the same script creates the dir. 23.39.09 Join perrikwp [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 23.39.16 # output ls -l and the arguments you give to rm every time, and see if it looks sane 23.39.36 Quit perrikwp (Read error: 104 (Connection reset by peer)) 23.39.42 # * gevaerts adds a client 23.39.57 Join perrikwp [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 23.40.00 # Zagor: I always use rm -rf to delete dirs 23.40.14 # also, there's no point saving $olddir in runclient.sh unless someone runs it with "source" (which is a bit silly) 23.40.15 # kugel: Including / ? :P 23.40.19 # also, I think if you leave the trailing slash, the dir itself isn't deleted 23.40.20 Join timc [0] (n=aoeu@116.3.7.51) 23.40.23 # (Sorry, couldn't resist) 23.40.34 # Mikachu: olddir? 23.40.36 # LambdaCalculus37: it's ok, you're forgiven :) 23.40.48 Join perrikwp__ [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 23.40.56 # Zagor: it does olddir="`pwd`" in runclient.sh, then cd "$olddir" at the end of the script 23.41.00 # after which point the shell process exits :) 23.41.11 # very unimportant though, you can keep it if you like 23.41.41 Join perrikwp___ [0] (n=perrikwp@rrcs-24-172-12-65.midsouth.biz.rr.com) 23.41.41 *** Alert Mode level 1 23.41.41 DBUG Sent KICK perrikwp_ to server 23.41.41 DBUG Sent KICK perrikwp to server 23.41.41 *** Alert Mode level 2 23.41.41 DBUG sent MODE #rockbox +b *!*n=perrik*@*.midsouth.biz.rr.com 23.41.41 DBUG Sent KICK perrikwp__ to server 23.41.41 DBUG Enqueued KICK perrikwp___ 23.41.41 *** Alert Mode level 3 23.41.42 DBUG Q-Sent KICK perrikwp___ to server 23.41.42 Kick (#rockbox perrikwp_ :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 23.41.42 *** Alert Mode level 4 23.41.42 Kick (#rockbox perrikwp :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 23.41.42 *** Alert Mode level 5 23.41.42 Mode "#rockbox +b *!*n=perrik*@*.midsouth.biz.rr.com " by logbot (n=bjst@rockbox/bot/logbot) 23.41.42 Kick (#rockbox perrikwp__ :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 23.41.42 *** Alert Mode level 6 23.41.42 Kick (#rockbox perrikwp___ :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 23.41.42 *** Alert Mode level 7 23.41.53 # duh 23.42.15 Quit Hendrik_ ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 23.42.16 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.42.28 # Mikachu: oh, I didn't see that. rasher added it. 23.42.33 # ah 23.43.13 # Hrm, yeah that's not very useful 23.43.19 # how about unbanning? 23.43.25 # rasher: I must admit I don't see the point :) 23.43.47 # Zagor: With the cd "`dirname $0`", or with the olddir stuff? 23.44.23 # trying to be smarter than the user, I think :) 23.44.48 # is this ban intended? 23.45.06 Quit n1s (Read error: 60 (Operation timed out)) 23.45.09 # kugel: it's automatic 23.45.17 # does it unban automatically too? 23.45.23 # was it always like that? 23.45.34 # I figured that it's automatic 23.45.41 # Zagor: the script requires that you're sitting in that dir, so why not make sure? 23.45.42 # you could just ban *_ in the first place 23.45.46 Join icebrian [0] (n=icebrian@a83-132-86-2.cpe.netcabo.pt) 23.45.49 #>> "is an old battle bot, so it can be a bit harsh" by Zagor (n=bjst@rockbox/developer/Zagor) 23.45.55 # not always. logbot tends to lose its op status every now and then 23.45.58 # rasher: if you're in the dir, but the script isn't, you broke it :) 23.46.01 # Mikachu: not a good idea 23.46.06 # *__ then 23.46.11 # neither 23.46.13 # still not :) 23.46.24 # Mikachu: say if I run /home/rasher/somedir/runclient.sh from cron, the cd is very helpful 23.46.28 # rasher: I'd rather have the script complain than trying to fix it 23.46.32 Join kperri [0] (n=18ac0c41@gateway/web/cgi-irc/labb.contactor.se/x-0bf2754fea51452c) 23.46.41 # rasher: running a script that has while true from cron is not the best idea ;) but sure 23.46.51 # Mikachu: @reboot 23.47.35 # rasher: run (cd /home/rasher/somedir && sh runclient.sh) instead 23.48.04 # What's the argument against it? 23.48.18 # cd myrockboxcheckout; ~/scripts/runclient.sh 23.49.00 # or if pwd is longer than PATH_MAX ;) 23.49.14 # The script complains about something it *knows* how to fix. That's just silly if you ask me 23.49.49 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 23.49.49 # * hillshum lets his system update 23.50.01 # * rasher shrugs 23.50.05 # Feel free to remove 23.50.49 # it doesn't know. the user could run it as Mikachu says. I don't think it's a good idea, but the auto-fix would not fix it- 23.51.23 # you could make the cd conditional on [ -f rbclient.pl ] but that could be a bit too magic 23.51.43 *** Alert Mode OFF 23.51.43 # hence I'd rather have it complain that something seems odd and have the user do it right instead. 23.52.11 # afterall it's for build servers that shouldn't do strange stuff anyway 23.52.28 # and instead of while true, you might want while sleep 60 or something, in case i break my perl installation, that script will busyloop 23.52.35 # * gevaerts isn't entirely sure how the new build system fixes the trust issue. People may not see the incoming ssh connections anymore, but the update is not authenticated, so could be defeated by dns attacks 23.52.56 # you mean the svn update? 23.53.05 # no, the build script update 23.53.50 # gah, I am an idiot. WNOHANG is not a good flag to use for waitpid if you really want to wait. copy/paste error :( 23.54.14 # Automatic updates won't work on cygwin due to windows' file locking shenanigans by the by 23.54.15 # boo zagor, you suck 23.54.40 # rasher: ah, right 23.54.43 # build servers on cygwin doesn't sound a brilliant idea anyway 23.55.09 # AlexP: maybe they will be needed for rbutil builds? 23.55.09 # we could reject those outright imo 23.55.25 # gevaerts: hmmm, could be 23.55.43 # you don't need cygwin for that AFAIK, just mingw 23.55.44 # gevaerts: yes, that is an issue. we discussed using SSL certificates for everything, but we're starting simple. 23.55.59 Quit kperri ("CGI:IRC (Ping timeout)") 23.56.46 # Zagor: runclient.sh could check for newrbclient.pl before running rbclient.pl I guess 23.56.49 # if you're worried about dns poisoning you need to secure the svn connection too, otherwise some joker can put rm -rf / in the makefile 23.57.32 # yup. there are many holes. 23.57.44 # Zagor: my build servers are VMs, so damage will be limited anyway. I just find it a bit ironic that people like this for its enhanced accountability (no external logins ever!) while actually being less secure :) 23.57.57 # but i think the target group is a little too small to motivate writing an exploit :) 23.58.00 # Hopefully people would set up a separate user for it 23.58.34 # gevaerts: I wouldn't say less secure. but not more either. the nice new thing is rather the more direct control you have, where you can start and stop as you like.