--- Log for 08.07.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 month and 5 days ago 00.00.04 Quit Nico_P (Remote closed the connection) 00.00.10 # I think my massive €29 travelling expenses can be considered a "donation" (in that I won't be claiming) :) 00.00.21 Join perrikwp1 [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) 00.00.39 # damn it!! i pull the cable, it then shows a message "file not found", then reboots with the gigabeat screen, and then i get a message saying "3 blah blah firmware restoration.." then it goest to screen "1 connect portable media center to a pc" 00.01.01 # * domonoky also "donates" his flight costs... may someone else who needs it get more.. 00.01.26 Quit Lss (Read error: 54 (Connection reset by peer)) 00.02.11 # redriot02: Welcome to the gigabeat S :( 00.02.47 # :O 00.03.00 # redriot02: Yeah. sounds like you're one of the people who can't use the single-boot bootloader 00.03.03 Quit domonoky (Read error: 104 (Connection reset by peer)) 00.03.05 # you have to use the dual boot 00.03.45 Join perrikwp2 [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) 00.04.09 # i couldnt find instructions on how to use dualboot 00.04.51 Join redriot [0] (n=18820f1b@gateway/web/cgi-irc/labb.contactor.se/x-62769e632cf2b524) 00.04.51 Quit redriot02 ("CGI:IRC (EOF)") 00.05.08 # http://www.rockbox.org/twiki/bin/view/Main/GigabeatSInstallation#Step_1b_Bootloader_installation 00.05.18 # oh, heh, sorry 00.05.21 # that section is blank. 00.05.56 # yeah 00.06.29 # redriot: http://www.rockbox.org/twiki/bin/view/Main/GigabeatSInfo#Loading_code_from_Linux 00.07.26 # does cook.codec build on sim for others? I seem to be missing some definition of __assert on cygwin build (although I will try a make clean and see if that fixes) 00.07.38 # though someone should edit that so that it doesn't refer to the patched gigabeat V firmware loader 00.07.42 # wait is this what the contents of partition #2 is supposed to look like ? 00.07.46 # http://files.getdropbox.com/u/66962/Screenshot%20-%207_7_2009%20%2C%203_07_11%20PM.png 00.08.18 Join perrikwp3 [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) 00.08.18 *** Alert Mode level 1 00.08.18 DBUG Sent KICK perrikwp to server 00.08.18 DBUG Sent KICK perrikwp1 to server 00.08.18 *** Alert Mode level 2 00.08.18 DBUG sent MODE #rockbox +b *!*n=Keith@*.se.biz.rr.com 00.08.18 DBUG Sent KICK perrikwp2 to server 00.08.18 DBUG Enqueued KICK perrikwp3 00.08.18 *** Alert Mode level 3 00.08.18 # yes. 00.08.18 # what's on partition 2 doesn't matter a lot 00.08.19 DBUG Q-Sent KICK perrikwp3 to server 00.08.19 # redriot: looks normal to me 00.08.20 Kick (#rockbox perrikwp :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 00.08.20 *** Alert Mode level 4 00.08.20 Kick (#rockbox perrikwp1 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 00.08.20 *** Alert Mode level 5 00.08.20 Mode "#rockbox +b *!*n=Keith@*.se.biz.rr.com " by logbot (n=bjst@rockbox/bot/logbot) 00.08.20 Kick (#rockbox perrikwp2 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 00.08.20 *** Alert Mode level 6 00.08.20 Kick (#rockbox perrikwp3 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot 00.08.20 *** Alert Mode level 7 00.08.42 # dang.. i was hoping thats what the problem was 00.08.48 # logbot getting aggressive again... 00.08.57 # you'll have to find the dual boot instructions, or wait until i work out why the later bootroms don't allow the single boot 00.09.00 # :) 00.09.11 # redriot: no, the flash bootloader doesn't like something about the single-boot bootloader 00.09.16 # I already linked the dual boot instructions 00.09.21 # TYorne are you the lead developer for gigabeat s ? 00.09.30 # redriot: it's pretty much because you have an OF later than 1.1 00.09.39 # Most of rockbox applies to most targets 00.10.00 # Of the hardware on the S, jhMikeS has done a lot (and Nico_P before him) 00.10.52 # no, i'm not a developer 00.10.53 # damn well now my gigabeat is unusable ? 00.10.59 # but i am reverse engineering the gigabeat s bootrom 00.11.09 # it's not unusable 00.11.13 # redriot: Try the dualboot bootloader 00.11.32 # make a dualboot bootloader, or just send it the original firmware again 00.12.07 Part captainkwel 00.12.12 # redriot: it's usable with the dualboot bootloader. It might still jump into recovery mode on bootup once or twice, but you can just toggle the battery switch and try again 00.13.49 # so complicated :/ 00.14.06 # That'd be why it isn't either supported or released 00.16.03 Quit robin0800 ("Leaving") 00.18.21 *** Alert Mode OFF 00.36.04 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 00.39.20 Quit tessarakt ("Client exiting") 00.39.59 Quit petur ("Zzzzzz") 00.40.09 Quit shotofadds ("Leaving") 00.40.50 # New commit by 03stripwax (r21704): Fix bug introduced in r21616 (my bad)- playlist moving array could show in playlist viewer even when track not being moved 00.41.14 # sigh. ^array^arrow 00.42.14 Quit bluebrother ("leaving") 00.44.13 Quit redriot ("CGI:IRC (EOF)") 00.45.37 Quit efyx_ (Remote closed the connection) 00.45.58 Quit DarkDefender ("Leaving") 00.49.10 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 00.49.35 Quit robin0800 (Client Quit) 00.50.57 Quit ender (" Generations have been working in jobs they hate, just so they can buy what they don't really need. -- Chuck Palahniuk") 00.53.59 *** Saving seen data "./dancer.seen" 00.54.09 # per-client stats for new build: http://build.rockbox.org/data/21700-clients.html 00.54.48 # the values don't quite add up though... 00.55.15 # sweet 00.55.19 # this particular build took 664 seconds wallclock time 00.55.25 # *build round 00.57.08 # weird 00.58.11 # just going by the total time numbers... shouldnt saratoga's client have been killed and mc2739's picked up more? 00.58.33 # I'm assuming that only completed builds are in that list? 00.58.34 # it's impossible to tell that based on the numbers alone 00.58.59 # JdGordon|: yes, only completed builds 01.00.06 # clearly some time measurements in the server are arong 01.00.08 # wrong 01.04.13 # it seems the sockets can go down without either the server or client noticing. both my machines at home just sat there when the last round started, and didn't get any builds. 01.04.49 # then the ping logic needs to be improved 01.05.01 # exactly, shouldn't the server complain about lack of _PING then? 01.05.20 # maybe it was something else 01.05.26 # perhaps we need something in the client that makes it give up and restart if it gets nothing within a certain time 01.05.33 # :O you're using _PING instead of PONG?! 01.05.48 # we do, the response messages are all _[message] 01.06.01 # but.. but.... :p 01.12.31 Join FOAD_ [0] (n=dok@dinah.blub.net) 01.19.10 # more fun numbers: http://build.rockbox.org/data/21704-clients.html 01.20.42 Join lee321987 [0] (n=chatzill@76.250.186.194) 01.21.15 # my client fell off somewhere? 01.21.27 # at least gevaerts didnt get top spot again :) 01.21.48 # Ever heard of a player not being recognized by the computer when in RB, but OF works fine? (Sansa c200) 01.22.27 # JdGordon|: unfortunately all your builds got cancelled... 01.22.38 # lame :p 01.23.54 # JdGordon|: what machine are you running? it seems odd that you don't even manage your first build 01.24.30 Quit FOAD (Read error: 110 (Connection timed out)) 01.24.30 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 01.24.31 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 01.24.37 # q6600 with 6gb ram and -j4 01.26.11 # JdGordon|: then something is wrong. you got assigned build creativezvm60 at 23:01:05 but at 23:12:05 you still hadn't finished, so got cancelled due to another server already having done it 01.26.38 Quit wincent (Read error: 60 (Operation timed out)) 01.27.50 # I apparently finished the yh820 build... 01.28.23 # back in 10 01.28.35 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.28.44 Quit lee321987 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 01.29.26 # Bagder: the time is counted from when the build was handed out... 01.29.46 # we need the client to report how long it took 01.35.51 Join JdGordon| [0] (i=460030b3@gateway/web/freenode/x-0400246b87e75526) 01.40.58 # New commit by 03zagor (r21705): Report how much time a build took. 01.43.40 Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) 01.46.12 # New commit by 03zagor (r21706): Get build time from client. 01.46.44 Quit Thundercloud (Remote closed the connection) 01.47.32 # New commit by 03zagor (r21707): Fix typo... :-| 01.49.37 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 01.57.26 Quit Zagor ("Clint excited") 02.04.42 Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) 02.13.59 Quit JdGordon| (Ping timeout: 180 seconds) 02.17.43 Quit Torne (Read error: 110 (Connection timed out)) 02.20.33 # Anyone around for a quick review of a patch? The last one in FS#7967. 02.20.59 # Fixes a bug in playlist.c - playlist_move . Would move the track to the wrong location if it crosses the playlist index boundary at the end 02.22.09 # Afaik playlist_move is only used from playlist_viewer.c , where the bug is easy to see/reproduce when moving tracks around in a *shuffled* playlist 02.27.57 # just commit it :) 02.29.19 # Yeah - works for me, must be good enough :) Anyway, grep doesn't lie, so -- done. 02.29.46 # grep doesnt lie... but it will give you the output you wernt hoping for if you use it wrong :) 02.30.27 # New commit by 03stripwax (r21708): Fix bug in playlist_move where the track would end up one place too early / too late if the move wrapped from one end of the playlist indices to the ... 02.36.21 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 02.36.21 # * JdGordon is pretty sure the statusbar handling in the wps is fundamentally broken :( 02.38.34 # or kkurbjun has sent me on a wild goose hunt :p 02.40.45 # JdGordon - who has powers to close a flyspray bug report? I think fs#7967 is done with now. 02.40.53 # you dont? 02.41.29 # i'll close it, but you should annoy Zagor or Bagder to fix it for you 02.42.35 # I don't know, I might have - if I do have, should it be obvious how? 02.42.55 # (Couldn't see any obvious way to close the bug so assumed I just didn't have the special power) 02.42.56 # yes, your in the wrong group 02.43.00 # ah 02.43.09 # * Mikachu can also close bugs, for some reason :) 02.43.42 # it would be nice if we had a single group management system for the whole project 02.44.31 # that wouldn't be very unixy 02.46.45 # good thing rockbox isn't unix :) 02.47.38 # darn, I should have put the FS in my svn comment. I'll try to remember to do so if I need to fix my fix :) 02.47.56 # * stripwax sleeps 02.48.25 Quit stripwax ("http://miranda-im.org") 02.51.07 # New commit by 03jdgordon (r21709): cleanup the remote+main statusbar handling a bit, and fix the bug where the remote wps might reserve the space for the statusbar even if its disabled 02.54.03 *** Saving seen data "./dancer.seen" 02.57.17 Join lee321987 [0] (n=chatzill@76.250.186.194) 02.58.47 # I have an e200R, but when I try to configure I get: "Do not use the e200R target for regular builds. Use e200 instead" 02.59.10 Quit patmulchrone (Remote closed the connection) 03.00.06 # What would be a "non-regular" build? 03.00.40 # the bootloader i guess 03.01.19 Join Blue_Dude [0] (n=chatzill@adsl-235-206-197.mco.bellsouth.net) 03.01.59 # I think I get it. So it should be ok to choose "e200" after configure, and install it onto an e200R? 03.03.00 # I'm having a hard time compiling. I keep getting an error: undefined reference to '___assert' in /libcook/bitstream.h 03.06.59 # I checked out a brand new unaltered trunk and it fails to compile. Any ideas? 03.08.41 Join mc2739 [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 03.11.08 # Zagor: for the logs -- 0-length pipe msg from 4! and Server refused connection: error duplicate name! 03.11.36 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 03.11.55 Quit lee321987 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 03.12.39 # JdGordon: I did some more testing on that bug and it looks like if you have a rwps that has a %wd tag it does not show the problem. The default wps seems to show it though 03.12.58 # svn up.. fixed 03.13.19 # oh nice 03.13.22 # I missed that 03.13.23 # :-D 03.14.40 # nice, I just tested it and it looks like it works fine 03.15.36 # I did find one other bug though which does not effect usability much, but when you plug the USB coord in it shows the statusbar on the remote regardless of the setting 03.15.53 # I'm not sure if it does that on the main unit too or if it is intended to do that 03.21.48 # yeah, saw there might be a issue there 03.32.35 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 03.38.10 # s/might be/is 03.38.25 # im not too woried about them though.. might fix this evening if i get around to it 03.43.13 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 03.47.57 Join BdN3504 [0] (n=5ce53b4e@gateway/web/cgi-irc/labb.contactor.se/x-afe40eb37987471d) 03.49.39 # kkurbjun hey karl are you still online? 03.53.41 Quit notlistening ("Leaving") 03.54.36 Quit dmb (Read error: 54 (Connection reset by peer)) 03.55.19 Join dmb [0] (n=Dmb@unaffiliated/dmb) 03.57.58 Part n00b81 ("Leaving") 04.04.40 Quit BdN3504 ("CGI:IRC (EOF)") 04.11.02 Quit safetydan ("Leaving.") 04.11.36 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 04.13.22 Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 04.16.00 Join evilnick_home [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) 04.24.06 Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 04.31.47 Join ReKleSS [0] (n=ReKleSS@d58-110-100-89.mas6.nsw.optusnet.com.au) 04.33.45 Quit evilnick_home1 (Read error: 110 (Connection timed out)) 04.46.58 Join patmulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) 04.54.07 *** Saving seen data "./dancer.seen" 04.54.40 Quit Sajber^ (Read error: 54 (Connection reset by peer)) 05.03.15 Join eido [0] (n=pc@user-160uvlr.cable.mindspring.com) 05.04.18 # can someone help me, i cant figure out what to view pictures with on a sansa e240 i got videos working after encoding them with winFF but i cannot seem to open pictures 05.05.02 # eido, only JPEG is supported. you should just be able to "play" them to view them 05.07.00 # ahh my bad they were bitmap 05.08.51 Join flyback [0] (n=osmosis@c-24-3-13-158.hsd1.pa.comcast.net) 05.09.28 Quit AndyI (Read error: 60 (Operation timed out)) 05.10.56 # safetydan, ty for the help 05.10.57 Join AndyI [0] (i=AndyI@212.14.205.32) 05.11.42 # haha 05.11.51 # you guys are even looking at cheap samsung soc ports 05.11.52 # awesome 05.12.03 # * flyback still has a j1mp3 player 05.14.20 Join rob [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) 05.14.30 Join civpro [0] (n=shawnmst@c-76-125-194-217.hsd1.wv.comcast.net) 05.14.36 Nick rob is now known as r0b- (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) 05.14.36 Join _lifeless [0] (n=lifeless@188.16.119.4) 05.27.08 Quit eido ("Leaving") 05.31.50 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 05.34.33 Quit civpro () 05.51.14 Quit Horscht ("Verlassend") 05.58.44 Join will_ [0] (n=will@unaffiliated/will) 05.58.48 # helloooooooooo 06.00.52 # New commit by 03kkurbjun (r21710): M:robe 500 - Set the mask on the remote so that it indicates the battery status 06.09.56 # So read through all the docs, having a little issue with OSX -> Sansa e260. It says it cannot open the Sansa. On the installation tab, I can install the software, but not the bootloader. 06.09.59 # Thoughts? 06.11.58 # is it a v2? 06.12.08 # whats the sansa firmware version? 06.16.28 # v1... 1 sec(it's rebuilding the db :) 06.17.08 # 01.02.18A 06.19.37 Join JdGordon| [0] (i=43a02c5a@gateway/web/freenode/x-612f42e9a7d74f9d) 06.21.14 # ok, doesok, you need to run rbutil as an admin 06.21.21 # I'm not sure how osx handles that 06.21.40 # ah 06.21.49 # sudo maybe hehe 06.22.23 # In the .dmg, it's "rbutilqt". Is that the same thing you're talking about (didn't want to assume) 06.22.44 # umm... maybe 06.22.47 # probably 06.24.49 Quit FOAD (Remote closed the connection) 06.26.57 # Hmm... Well, I get "[INFO] Scanning disk devices...\n[INFO] e200 found - /dev/disk2\n No such file or directory" 06.27.47 # i think youve come at a bad time... you might want to have a look on the forums for help... 06.27.58 # or try doing the manual install if you're game 06.28.54 # Hmm... I wonder if my Sansa is busted. When I tried to plug it into Linux (fedora11), it can't mount it. It can mount in OSX though 06.28.59 # Ok, I might give that a shot. 06.30.23 # the linux probl;em could be a knon issue with lipgphoto 06.30.26 # lib* 06.30.55 # ah 06.33.41 Join bluefoxx [0] (i=bluefoxx@S0106005004792985.vs.shawcable.net) 06.35.20 # So, I have a Sansa e200 once again, and of course, it /has/ to have rockbox on it. Now the last time i did the bootloader I wanted the version that does away with the OF, but when I tried it the player came out bricked(had to repatch it). Also, I want to save a copy of the origional FW and bootloader somehow, If thats at all possible... 06.37.19 # 404.. question not found? 06.38.08 # JdGordon: Do you know a guy named Mark Pulver? 06.38.23 # doesnt ring a bell 06.38.27 # darn ok 06.43.32 # JdGordon|: Ah nice, manual install worked. Thanks a bunch! 06.44.19 # :) 06.50.59 # So nobody can assist me in ripping the firmware from a v1 e200? 06.53.52 # This is my first day with Rockbox :) 06.54.08 *** Saving seen data "./dancer.seen" 06.54.08 # you havnt actually asked a question... 06.55.04 # JdGordon|: You mean me? 06.55.25 Join __lifeless [0] (n=lifeless@188.16.119.4) 06.55.37 # yes 06.57.00 # I'm asking how I make a .mi4 file of the current firmware of the sansa e200 I have, since every other .mi4 that restores the origional FW I've found has done things like crash the player while it's trying to connect to USB or just randomly green-screens 07.10.48 Quit _lifeless (Read error: 113 (No route to host)) 07.14.10 Join n1s [0] (n=n1s@rockbox/developer/n1s) 07.22.52 Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 07.26.07 Quit bluefoxx ("Help not found.") 07.32.59 Quit pixelma (Nick collision from services.) 07.33.00 Quit amiconn (Nick collision from services.) 07.33.00 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 07.33.02 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 07.33.18 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 07.33.22 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 07.42.29 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 07.49.34 Join gartral [0] (n=Gartral@adsl-75-33-64-21.dsl.bcvloh.sbcglobal.net) 07.49.59 # heya guys, I have a sansa e250 here that sansapatcher *refuses* to belive is a sansa... 07.50.48 # gartral: What firmware version? 07.51.18 # Llorean: I cant tell.. the scree is smashed in 07.51.36 # but I know it's in msc mode 07.51.46 # lol 07.51.49 Quit JdGordon| (Ping timeout: 180 seconds) 07.51.51 # (sorry) 07.51.52 # gartral: So how do you know it's a V1? 07.52.03 # its also running an old Rockbox version 07.52.24 # How was Rockbox installed without Sansapatcher recognizing it? 07.52.38 # Windows + rbutil 07.53.23 # rbutil uses the exact same code as sansapatcher. Literally. 07.54.04 # Why aren't you using rbutil, anyway? 07.54.05 # I know.. that's whats wierd 07.54.22 # trying to install 7pre4 bootloader 07.55.03 # Err, there's no 7pre4 for sansas 07.55.58 # ermm.. ok, which ever one is the bootloader that makes it boot too RB on USB insert 07.56.20 # You mean the one from the flyspray task? Why didn't you just refer to it as such? 07.56.42 # I honestly thought it was a varient of 7pre4.. >.> 07.57.41 # http://gar.pastebin.com/f29c75381 heres the error 07.58.19 # You're not supposed to point it at the mount point. 07.58.48 # ohh.. 08.04.56 # In fact, it's not supposed to be mounted at all 08.08.54 # http://www.sparkfun.com/commerce/product_info.php?products_id=9237 08.10.11 Part will_ ("Leaving") 08.12.59 # how do i determine the device node? [dev/sdX structure was thrown out the window for Jaunty >.<] 08.18.33 Quit DarkSpectrum (Read error: 104 (Connection reset by peer)) 08.20.19 # im just haveing one of thos re-re days >.> 08.20.59 # lsusb 08.21.01 # :P 08.21.06 # dmesg and grep it for the same thing etc 08.21.54 # Have you tried simply running sansapatcher without parameters so it can autodetect? 08.22.12 # that's what I just did, reports dev/sdc 08.24.48 # ok, all done.. thank you much Llorean 08.29.13 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.31.46 # /dev/sdX was NOT thrown out of the window in jaunty - that's complete tosh 08.33.35 # yes, I discovered that... but it isnt "visable" from command line.. and was annoying 08.34.31 # what isn't visible ? 08.34.38 Part safetydan ("Leaving.") 08.35.20 Join Grahack1 [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 08.37.28 # any /dev/sdXX device nodes 08.39.18 # that's also rubbish 08.39.50 # do you want a screenshot? I swear i cant see them 08.40.32 # you wont see any if nothing is attached 08.40.40 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 08.41.04 # JdGordon: I have 3 flashdrives, and a dap plugged in almost 24/7 08.42.38 # gartral: so "ls /dev/sd*" lists nothing at all is what you're saying 08.45.00 # that works... but cd /dev/ && ls doesn't show them 08.45.28 # which makes no sense what so ever.. 08.46.07 # it makes so little sense that i don't believe it's happening. 08.46.21 # This is pretty off-topic in here at this point anyway. Basic computer use stuff. 08.46.57 # ;opens mouth and insert foot 08.48.47 # gartral: And in the future, try to actually read the documentation on how to use a tool before claiming it doesn't work. This isn't the first time you've claimed something is broken or isn't working right, and it's turned out you just weren't careful. 08.49.31 Quit Grahack (Read error: 110 (Connection timed out)) 08.50.35 # yea.. i know.. im a bit jumpy... 08.50.42 # sorry 08.54.10 *** Saving seen data "./dancer.seen" 08.55.46 Join Rob2222 [0] (n=Miranda@p4FDCF7A5.dip.t-dialin.net) 08.56.34 # Bagder: It looks like the new buildclient doesn't reconnect if it was running during a network disconnect, at least if it was a longer one 08.57.13 # yeah, we discussed that last night 08.57.22 # the client doesn't seem to notice the disconnect 08.58.20 Quit Telazorn (Read error: 110 (Connection timed out)) 09.02.08 # * amiconn also wonders what's up with the locked svn working copy on one of the new buildclients 09.03.11 # amiconn: can you tell which one ? 09.05.06 # hm, I guess we risk that with killed builds... 09.08.04 # my client is being told "duplicate name" at the moment 09.11.24 Join petur [50] (n=petur@rockbox/developer/petur) 09.12.29 # It seems the server doesn't cope with disappearing-then-reappearing clients very well 09.13.04 Quit Rob2223 (Read error: 110 (Connection timed out)) 09.15.02 # Bagder: svn cleanup seems to be rather cheap, so maybe just run that always before building? 09.15.18 # yes, I believe so too 09.15.31 # or even before svn update 09.15.57 # Why does killing builds risk a locked working copy? 09.16.12 # if the svn operation gets killed 09.16.51 # Hmm. Couldn't we ensure that 'svn update' never gets killed? 09.17.16 # If a build is killed while svn updates, just let svn update finish and then stop 09.17.44 # well, that's potentially a very long and slow operation 09.17.59 # so it'd be wasted cpu time 09.20.29 Join jfc^2 [0] (n=john@dpc691978010.direcpc.com) 09.22.07 Join AndyIL [0] (i=AndyI@212.14.205.32) 09.22.48 # The client needs to update svn anyway if it wants to participate at all 09.23.08 # yes, but next build might be to another rev 09.25.02 # my client has been booted again with another duplicate name error 09.25.24 # mine too 09.25.44 # clearly it "leaks" client names 09.28.36 Join Thundercloud [0] (i=thunderc@81.187.69.84) 09.33.09 Quit AndyI (Read error: 110 (Connection timed out)) 09.36.21 Quit jfc (Read error: 110 (Connection timed out)) 09.48.58 # does the H120 have a hardware watchdog or something? 09.49.08 # I think I've gotten the cpu to halt, but it still powers down after a second or so 09.49.20 # it doesn't 09.49.22 Quit n1s (Read error: 110 (Connection timed out)) 09.49.30 # ok 09.49.48 # any idea why it's powering down? 09.50.55 Quit Thundercloud (Remote closed the connection) 09.56.01 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 10.08.42 Quit gartral ("Lost terminal") 10.10.41 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 10.16.50 # Bagder: rasher's binsize build client also tends to get stuck connections on network changes, using plain netcat. Not sure if this is useful information 10.17.43 # I think we can just timeout the clients if nothing was "heard" from the server in say 60 seconds 10.17.59 # the server sends a ping much more frequently than so 10.18.06 Quit Zarggg () 10.19.33 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 10.22.51 Join bluefoxx [0] (i=bluefoxx@S0106005004792985.vs.shawcable.net) 10.23.07 # it could be the client's read() or write() itself that's stuck. 10.23.16 # they're non-blocking 10.23.30 # or should be 10.23.30 # So I managed to rip the firmware from my mp3 player, if anyone wants a copy of some old firmware for the e200 series that isn't buggy... 10.24.58 # http://daniel.haxx.se/sansa/fw/ ... 10.25.54 # I've in the past tried .mi4 files from places like his site and links on the rockbox site and found myself with a shiny brick whenever the stock firmware tried to do a database refresh... 10.26.08 # I only know that I've seen netcat stay stuck for weeks. I have no idea how these things actually work :) 10.26.17 # bluefoxx: those are all official versions 10.26.20 # it happens to sansas that my friends have after they update to newer firmware too i've found... 10.26.26 # and I bet your version is one of them 10.27.04 Join mt [0] (n=MTee@41.206.134.249) 10.27.11 # bluefoxx: you do know that you need to update the bootloader and main firmware together, right? 10.27.25 # hmn? 10.27.58 # Bagder: My version is about as early as i can find 10.28.06 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 10.28.12 # came from a barely used sansa that was bought when they just came out 10.28.16 Quit BHSPitMonkey ("Ex-Chat") 10.29.05 # without version number? :-) 10.29.13 # I don't understand what this fixation on "early" is. Plenty of people use later versions without any trouble. Is your Sansa broken, and this one just shows the fewest bugs? 10.29.37 # Llorean: stock firmware borks on database refresh after updates on my 10.29.39 # me* 10.29.50 # let me dig out a picture of what it did... 10.29.52 # that's usually due to fs problems 10.30.50 Join n1s [0] (n=n1s@rockbox/developer/n1s) 10.31.34 Join FOAD [0] (n=dok@dinah.blub.net) 10.32.03 # bluefoxx: did you install the corresponding BL file at the same time? 10.32.18 Quit kachna|lappy (Read error: 113 (No route to host)) 10.32.20 # gevaerts: i'm not sure what your talking about here... 10.32.34 # bluefoxx: have another look at http://daniel.haxx.se/sansa/fw/ then 10.33.13 # There's PP5022.mi4 and BL_SD_boardSupportSD.rom. Did you update both of them? 10.33.41 # * gevaerts knows that at least on c200, if you don 10.33.46 # 't do this, you get problems 10.34.12 # on the e200 you can mostly just update the fw part 10.34.18 # This usually happens after following the unbrick FAQ, which caused me to seek out http://www.rockbox.org/twiki/bin/view/Main/SansaFAQ#Can_I_disable_the_Sansa_c200_fir 10.34.55 # Bagder: even if the bootloader is very early? 10.35.18 # both of which caused the thing to freak out under stock FW when it tried to do database refreshes 10.35.26 # I'm not sure, but during my experimentations I rarely replaced the BL one 10.35.30 # http://i31.tinypic.com/2r6mamh.jpg 10.35.35 # is what would tend to happen 10.35.46 # or similar things but with green or blue lines 10.36.26 # that time was rockbox freaking out at me after an update was suggested, but thats the general idea of what happens... 10.37.27 # That seems like a hardware problem, especially if it's also happening in Rockbox. 10.37.31 Quit martian67 (Read error: 60 (Operation timed out)) 10.37.39 # Anyway, I'd say that either your filesystem is corrupted, or the bootloader and main firmware don't match. If it's the filesystem and chkdsk/fsck.vfat don't help, try sansa.fmt first 10.37.41 # i've seen it on at least 6 sansas now 10.38.12 # * gevaerts thinks that if one person sees this on all sansas he touches, and nobody else sees it, there seems to be a clear correlation 10.38.17 # http://i26.tinypic.com/10ie2vm.jpg is what the firmware update causes on database refreshes 10.38.23 # and no, its not on any that i touch 10.38.37 # bluefoxx: Seriously, nobody else has ever reported this problem to us with Rockbox. 10.38.46 # i've several friends who have sansas. they update the firmware, that happens. 10.39.08 # anyways, thats what the .mi4 files i got off the website did to me 10.39.09 # maybe you're cursed? B) 10.39.13 # bluefoxx: you still haven't said if you actually updated the bootloader as well 10.39.15 # my friends don't use rockbox 10.39.34 # i used the latest sansapatcher.exe file i found if thats what you mean 10.39.35 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 10.39.42 # i don't bother with the OF myself if i can't help it 10.40.02 # that's *not* what I mean 10.40.11 # then what *do* you mean? 10.40.17 # BL_SD_boardSupportSD.rom 10.40.37 # ? 10.40.38 Quit martian67 (SendQ exceeded) 10.40.43 # * gevaerts gives up 10.40.49 # * GodEater doesn't blame gevaerts 10.41.25 # bah, whatever. rockbox works on the thing again, i have my firmware file to use. i'm going to bed before i start passing out when i stand up again. 10.41.29 Quit bluefoxx ("bye") 10.41.49 # Bagder: I wonder whether this non-awareness of disconnects is a linux problem. I've seen XChat on linux need more than 15 minutes to detect a broken connection, whereas on windows it usually needs less than a minute 10.42.01 Quit Unhelpful (Read error: 113 (No route to host)) 10.42.19 # Using some sort of heartbeat packets would probably help 10.42.47 # it's TCP 10.42.57 # it's designed to not notice idleness 10.44.08 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 10.54.12 *** Saving seen data "./dancer.seen" 10.55.54 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 10.58.46 # Bagder: do you use SO_KEEPALIVE? 11.09.54 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 11.10.48 Quit martian67_ (SendQ exceeded) 11.11.21 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 11.18.34 Quit martian67 (Read error: 110 (Connection timed out)) 11.21.04 Quit martian67_ (Read error: 60 (Operation timed out)) 11.25.01 Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 11.26.56 Join kachna|lappy [0] (n=kachna@r3g248.net.upc.cz) 11.32.43 Join kugel [0] (n=kugel@rockbox/developer/kugel) 11.35.58 Join Sylvai1 [0] (n=sylvain@ABordeaux-256-1-38-18.w90-11.abo.wanadoo.fr) 11.36.08 # Hi 11.36.26 # someone may help me ? I have a question about rockbox 11.36.59 # I have some files I don't want to register in database 11.37.21 # are they all in the same directory? 11.37.33 # I remember that it's possible to put a file name ".unregister" or something like this, but I don't remember the exact correct name 11.37.35 # yes 11.37.39 # database.ignore 11.37.45 # thank you 11.37.50 # there is one in your .rockbox dir 11.37.53 # so, on my iPod 11.38.47 # I can put a file "database.ignore" in root folder, and a "database.unignore" file in Music/ folder, if I want to analyse only files from this Music/ folder ? 11.39.03 Join Torne [0] (i=torne@lowell.wolfpuppy.org.uk) 11.39.08 Quit daurn (Read error: 104 (Connection reset by peer)) 11.39.14 Join daurn [0] (n=daurnima@unaffiliated/daurnimator) 11.39.24 # i think so, yes 11.39.42 # I think so also, I did it ago 11.39.46 # thank you 11.39.47 # bye 11.39.57 # :) 11.40.02 Part Sylvai1 11.45.28 # Mikachu: grml 11.45.33 # we were about to remove that possiblity for speeding things up :/ 11.45.39 # or we at least thought about it 11.45.57 # well it *is* still there 11.46.35 # * gevaerts proposes a setting for it ;) 11.49.16 # * GodEater still thinks it was a dumb idea in the first place :( 11.49.36 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 11.49.46 # * kugel agrees with GodEater 11.50.19 Quit n1s (Read error: 110 (Connection timed out)) 11.53.09 # mcuelenaere: hi, great you are here, I was trying to work on the Lua plugin myself (C newbie though), and I have several things to say. You seem to appear each time at the good moment 11.53.17 # 1) what is the difference between 'const unsigned char* str' and 'const char* str' ? 11.53.30 # that's a C question in general ;) 11.53.54 # the first is unsigned, the other is signed or unsigned depending on the compiler 11.54.03 # a char is on all our targets 8 bits, and when it's unsigned, it uses all those 8 bits for data storage 11.54.20 # it uses all 8 bits when it's signed as well 11.54.21 # mcuelenaere: it always does that... 11.54.21 # when signed, it only uses 7 bits and the 8 bit to store whether it's a negative or positive number 11.54.47 # gevaerts: not when it's signed, doesn't it? 11.54.48 # whether char is signed or not makes absolutely no difference to anything other than "what happens when you cast it to a wider type" 11.54.49 # that's not exactly true 11.55.01 # mcuelenaere: that sign bit is also data... 11.55.01 # mcuelenaere, Grahack1 wants bindings to the funcs in unicode.c, you able to bind them for him? 11.55.22 # mcuelenaere: -0 isn't encoded, that is used for -128, so there is 1/256th data in the sign bit :) 11.55.44 # ok, I was wrong then :) 11.55.47 # mcuelenaere: char represents one of 256 values, whether it's signed or not 11.56.07 # daurn: I was making progress this way, maybe I won't need him to make it who knows... just some help 11.56.12 # with unsigned char, the high bit is valued 128, with signed it's -128 11.56.18 # daurn: are they exposed over the plugin struct? 11.56.52 # Torne: sure, but they have a different meaning 11.56.54 # but yeah, saying it isn't used for data in signed is like saying it's used for saying if the value is higher or lower than 127 in unsigned 11.57.10 # * mcuelenaere decides to read the logs 11.57.15 # mcuelenaere: not until you cast to something else 11.57.39 # so this seems to bea good question, on which the team has different ideas :) 11.57.42 # Torne: or try to compare them 11.58.00 # dz: see under casting to something else :) 11.58.06 # comparing unlike types is coercion 11.58.15 # Torne: not really. 0xff > 0x01 ? 11.58.49 # is there anyone here interested/involved in the dev of the Lua plugin apart from mcuelenaere? 11.58.52 # gevaerts: always, yes, there is no 0xff from C's pov if it's signed :) 11.59.07 # Torne: 0xfe > 0x01? :) 11.59.07 # Torne: example, does a character fall within the range of ASCII? > 127 or < 0, depending on if it's signed or unsigned 11.59.09 # Grahack1: safetydan did the initial Lua porting 11.59.12 Quit Rob2222 () 11.59.18 # Even if they're both the same type, that depends on whether they are signed. No casting involved 11.59.38 # gevaerts: but there's no such thing as a signed char with value 0xfe, is my point there :) 11.59.43 # mcuelenaere: 2) I noticed a weird difference of behaviour on the sim and on my DAP. In some Lua code, the sim does 3%2 = 1 and 2^3 = 1 and the DAP 3%2 = 3 and 2^3 = 0 11.59.50 # there's one with in-memory representation of 0xfe but C doesn't care 12.00.06 # Torne: true, but sometimes that matters 12.00.16 # Grahack1: hmm, will look into it; what is the ^ operator supposed to do in Lua? 12.00.32 # i.e. if you write them to disk and read them back on another arch where default signedness is different 12.00.54 # ^ is the power operator 12.01.49 # it needs the math lib, which I'm trying to code in pure Lua (well, basic functions) 12.02.18 # hmm pow() is currently an empty function currently (returning 0 12.02.20 # ) 12.02.39 # so the sim is using a different one than the DAP is 12.03.12 # BTW do you have plans for the math lib ? not putting pressure at all because I sorted my problems with my libmath, but just to know 12.03.19 # mcuelenaere, could you instead just floor the exponent, and multiply it out? 12.03.33 Join Sajber^ [0] (n=Sajber@h-142-185.A213.priv.bahnhof.se) 12.04.19 # daurn: why floor the exponent? it isn't a float value 12.04.22 # (not in Rockbox) 12.04.34 # mcuelenaere, ok then, don't :P 12.05.17 # well ideally, at some point some of my integer hacks in Lua should get removed and that patch that separates float and integer usage should get applied 12.10.48 Quit linuxstb (Remote closed the connection) 12.10.52 # So there is hope. My libmath is in this zip, with test_libmath.lua that shows % and ^ issues if libmath not used: http://fezzik.free.fr/tmp/grualibs.zip 12.11.53 # Grahack1: well, 'at some point' doesn't mean in the near future ;) 12.14.38 # I'll be patient, it will be nice even in 10 years. 12.14.40 # Grahack1: if the utf8 functions you need are exported through the plugin struct, they should get wrapped to Lua automatically 12.16.15 # you mean if it's in this page ? http://mcuelenaere.alwaysdata.net/rockbox_api_example_3/list.html 12.16.53 # (the relevant text file in my source tree should be up to date) 12.17.05 # ehm yes, but that's an old one; try http://svn.rockbox.org/viewvc.cgi/trunk/apps/plugin.h?view=markup (starting at struct plugin_api { 12.17.21 # or docs/PLUGIN_API 12.17.25 # (and I'm 'planning' to rework the API documentator thingy) 12.17.32 # that's also outdated I think 12.17.53 # arf, I'll look into plugin.h then 12.18.41 # actually, rockbox_api_example_3 is based on docs/PLUGIN_API 12.19.40 # generated from the head of the svn repo ? 12.20.52 Quit mt (Read error: 110 (Connection timed out)) 12.20.57 # yes, but at that time though 12.21.24 # (it isn't updated since then probably though) 12.23.43 # Grahack1, seems you already have the funcs then :D 12.23.50 # it seems that some are: utf8decode iso_decode utf16LEdecode utf16BEdecode utf8encode 12.24.06 # yeah I looked into utf8decode, and that probably requires manual porting 12.24.11 # because of the unsigned short* ucs part 12.24.27 # (which rocklib_aux.pl can't handle) 12.25.12 # New commit by 03zagor (r21711): Fail more gracefully on svn error. 12.26.40 # mcuelenaere: this is the only three conversion functions I need to implement: http://code.google.com/p/lomp/source/browse/trunk/general.lua#68 12.26.51 # Hello all! How can I change the sampling rate on UI simulator? 12.27.55 # hmm that'll probably require some new Lua type as Lua won't be able to handle UTF-16 12.29.18 Join BdN3504 [0] (n=5ce53b4e@gateway/web/cgi-irc/labb.contactor.se/x-4f565c59e6d1025a) 12.29.20 # Bagder / zagor: What does e.g. Failed build iaudiom5sim: Status 256 12.29.21 # * mcuelenaere wonders why Grahack1 wants to port a music player app through Lua on a music playing firmware 12.29.26 # ...mean 12.29.34 # mcuelenaere, its just strings 12.29.53 # is it normal, that i get the error: "first allocation unit is not valid" when i run chkdsk on my sansa e270? 12.30.00 # v1 that is 12.30.35 # daurn: yes, but UTF-16 strings contains lots of 0 and Lua can only handle null-terminated strings 12.30.41 Join Rob2222 [0] (n=Miranda@p4FDCF7A5.dip.t-dialin.net) 12.30.46 # Grahack1, you need utf16BE, ascii , utf8 and utf16 conversion for id3v2 12.30.48 # I don't want to port the whole app, only the read/write tag things. Through Lua because I don't want to learn C. 12.31.08 # mcuelenaere, lua doesn't have null terminated strings at all, strings are 8bit safe 12.31.21 # daurn: I was indeed looking where those functions were needed 12.31.28 # daurn: ah it does? 12.31.37 # mcuelenaere, of course 12.35.42 # Grahack1: see firmware/common/unicode.c for a description of what those functions do 12.42.26 # Grahack1, typo fixed in newest commit :) 12.42.58 Quit kugel (Read error: 104 (Connection reset by peer)) 12.46.08 Quit __lifeless (Remote closed the connection) 12.49.12 # scandisk seemingly repaired tha FAT, but now the volume is shown as a removable disk as opposed to local on "my computer" (i'm using winxp pro). 12.50.09 # Grahack1, you seem to have every function you need already... 12.51.03 # oh, cept the BOM reading function is #if 0'd out 12.51.25 # rockbox woN't have any difficulties dealing with this, will it? 12.54.17 *** Saving seen data "./dancer.seen" 12.59.02 # daurn: I'm trying to figure out what parameters to give them to make them mimic your functions 13.00.15 # Grahack1, shouldn't be too hard if the functions are bound reasonably.... 13.10.45 Join kugel [0] (n=kugel@rockbox/developer/kugel) 13.12.34 # gevaerts: what's the dual boot button? 13.18.37 Join Unhelpful [0] (n=Militant@rockbox/developer/Unhelpful) 13.20.20 Quit BdN3504 ("CGI:IRC (EOF)") 13.27.08 Join rodpod [0] (n=rod@74-133-38-196.dhcp.insightbb.com) 13.27.57 Join desowin [0] (n=desowin@atheme/member/desowin) 13.28.29 # * gevaerts doesn't know 13.30.16 # gevaerts: found it by looking at the code... 13.32.49 Join boobaloo [0] (n=boobaloo@84.42.45.44) 13.33.04 Quit gevaerts (Nick collision from services.) 13.33.14 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 13.33.29 # we do have a manual you know ;) 13.41.23 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 13.45.39 Join Universal [0] (n=Unvrsal@user-54479ea3.wfd85b.dsl.pol.co.uk) 13.48.50 Quit kugel (Read error: 110 (Connection timed out)) 13.56.25 Join petur2 [50] (n=petur@rockbox/developer/petur) 13.56.45 Quit petur (Nick collision from services.) 13.56.48 Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) 13.59.07 # New commit by 03mcuelenaere (r21712): Lua: expose SCREEN_MAIN & SCREEN_REMOTE (for rb.lcd_*() functions) 14.09.50 Quit lilltiger (Remote closed the connection) 14.10.29 # mcuelenaere: hi. You could even do something like: rb.lcd:putsxy() and rb.remote:putsxy() (no need to add an extra argument to specify the screen) 14.11.30 # hmm and then rb.lcd & rb.remote is a metatable containing the constant? 14.12.27 Quit Universal ("Leaving") 14.12.56 # mcuelenaere: rb.lcd/remote would be tables containing that constant and they would share the same meta table to define the methods 14.13.21 # kind of like 2 instances of the same class (in OOP speak) 14.13.48 # it's just an idea I had when reading your commit message :) 14.14.17 # yes, a bit like rockbox images are currently handled 14.14.21 # I'll put it on my TODO list :) 14.14.23 # dionoea, it would be bettter if it was the screen/contents that could be operated on 14.14.50 # eg, mybmp:putlcd ( x ,y ) and mybmp:putremote( x , y ) 14.14.55 # s/mybmp/mytext/ 14.16.01 # mcuelenaere: ok :) I can have a look too if you want 14.16.40 # dionoea: sure 14.17.24 # daurn: and what's mytext? (an instance of .. ?) 14.17.28 # I have a 5 day week-end coming up ... so that should leave me some time to code 14.17.36 # mcuelenaere, could be a string, or anything really 14.17.55 # daurn: the action is really lcd specific, not string specific 14.18.03 # so it belongs in an lcd class IMO 14.18.06 # oh, are putlcd and putremote global methods here? 14.18.15 # and I agree with dionoea 14.18.20 Join kugel [0] (n=kugel@rockbox/developer/kugel) 14.18.25 # no, they are in the string's __index metatable 14.18.33 Quit kugel (Read error: 104 (Connection reset by peer)) 14.18.34 # that sounds a bit hacky 14.18.44 Join kugel_ [0] (n=kugel@e178108120.adsl.alicedsl.de) 14.18.47 # bbl 14.18.50 Nick kugel_ is now known as kugel (n=kugel@e178108120.adsl.alicedsl.de) 14.19.00 # so you rather lcd:putstring ( mystring , x , y ) ? 14.19.08 # gevaerts: it's not mentioned there, hence I needed to look at the code 14.20.44 # daurn: no, lcd:putstring(x, y, mystring) looks better :D 14.20.59 Quit boobaloo ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 14.21.01 # daurn: there's no putstring method 14.21.06 # someone give the clip sim button descriptions :S 14.21.24 # and yes, it looks better to me IMO (and fits the original Rockbox API) 14.21.30 # * daurn made up putstring, but whatever you use to print a string on the screen, or w/e 14.23.08 # mcuelenaere: does lua run on all the targets? 14.23.15 Quit robin0800 ("Leaving") 14.23.22 # dionoea: all those with PLUGIN_RAM_SIZE > some value 14.23.25 # (if yes I'll see if I can port some of the games to lua, like solitaire) 14.23.27 # ah ok 14.23.33 Join robin0800 [0] (n=robin080@81.98.157.181) 14.23.48 # dionoea: #if (PLUGIN_BUFFER_SIZE >= 0x80000) 14.24.08 # so most of them 14.24.38 # I'll do it as a poc then :D 14.25.01 # Grahack1, you there? 14.25.07 # dionoea, poc? 14.25.50 # proof of concept 14.25.56 # kugel: http://download.rockbox.org/manual/rockbox-h100/rockbox-buildch3.html#x5-260003.1.3 14.26.18 # gevaerts: eh 14.26.34 # I searched for "dual boot" and "dualboot", but not "dual-boot" :/ 14.26.47 # and it's wrong anyway. 14.26.51 # You need REC only 14.29.16 # but my lecturer was very enthusiastic and impressed by rockbox 14.31.06 # did you show doom? 14.31.34 # no, he saw , but didn't start it 14.39.24 Quit robin0800 ("Leaving") 14.39.39 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 14.39.49 Join petur2 [50] (n=petur@rockbox/developer/petur) 14.40.06 Quit petur (Nick collision from services.) 14.40.11 Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) 14.42.21 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 14.45.18 # New commit by 03kugel (r21713): Make the Sansa Clip and Fuze sim keymapping more like other Sansas with regard to the use of the numpad 14.47.08 # Erp, lots and lots of failed builds from my buildclient 14.48.17 # Ah, "svn: No such revision 22000" 14.48.20 # Naughty 14.48.41 Join LambdaCalculus37 [0] (i=44a0430d@gateway/web/freenode/x-90639414ff8171f0) 14.49.08 Quit Far^Side ("Leaving") 14.54.21 *** Saving seen data "./dancer.seen" 14.54.52 Join petur2 [50] (n=petur@rockbox/developer/petur) 14.55.05 Quit petur (Nick collision from services.) 14.55.09 Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) 14.55.39 Quit Bombe (Remote closed the connection) 14.57.24 Join MxxCon [0] (i=donuts@ool-18b9baa8.dyn.optonline.net) 14.58.25 # hey folks. changelog for 3.3 says some targets don't update the screen w/ backlight off. for sansa e200, so i have to do anything or it's enabled by default? 14.59.13 # (sorry for grammar, didn't have my coffee yet) 14.59.21 # I 14.59.29 # I'm pretty sure it's enabled by default 15.03.32 # MxxCon: you can't even disable it 15.05.08 # kugel: is there a define to enable this behaviour? 15.06.41 # mcuelenaere: yes, HAVE_LCD_ENABLE || HAVE_LCD_SLEE 15.06.44 # P 15.06.58 # i didn't want to disable it, just want to make sure that it was on 15.07.06 # kugel: ok, thanks 15.07.12 # MxxCon: I meant to say it is always on 15.07.43 # cool, thanx 15.11.02 # I can't help wondering how valid Torne's comments are on FS#9708, given he's running a build with other patches in it too... 15.11.19 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 15.16.31 Part MxxCon 15.18.20 # gevaerts: do I need to do anything special to get USB mass storage to work when defining HAVE_HOTSWAP? 15.19.08 Join teru [0] (n=teru@KD059133112132.ppp.dion.ne.jp) 15.31.14 Join mt [0] (n=MTee@41.206.137.199) 15.33.06 # is there a description of the rockbox.iriver format somewhere? 15.35.12 # ReKleSS: look in tools/scramble.c 15.35.45 # ok 15.35.57 # mt: did you read my comment regarding closing FS#10182 ? 15.36.15 Quit CaptainKewl (Remote closed the connection) 15.36.21 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 15.36.27 # teru: hey. welcome \0/ 15.36.49 # ReKleSS: the iriver format seems to be in tools/iriver.c 15.37.51 # mcuelenaere: No, where ? 15.37.59 # mcuelenaere: I think that's only about patching the OF file 15.38.21 # mt: in the logs somewhere :) I was wondering whether the flyspray entry shouldn't get closed now that you've committed it? 15.38.51 # or maybe not 15.38.53 # kugel: uh, isn't that how Rockbox generates the rockbox.iriver files? (iriver_encode) 15.39.02 # iriver.c seems to be for the original firmware, not for the rockbox.iriver 15.39.21 # scramble.c calls iriver_encode(), which is in iriver.c 15.39.30 # mcuelenaere: Isn't that the ".hex" format for the original firmware? The Rockbox binaries are created with the "$tool" command set in configure - probably "scramble -add" which just adds a simple 8-byte header. 15.39.45 # rockbox.iriver is made with scramble -add 15.39.47 # ah ok, sorry 15.39.58 # * mcuelenaere didn't look in tools/configure 15.40.33 # mcuelenaere: re: your last comment in the task, it depends if the variables are on the stack for the caller 15.40.49 # but stack is also memory, so it doesn't really matter. 15.40.58 # yeah but it's more dynamic 15.41.05 # but anyway, that's unrelated to mt's work 15.41.19 # mcuelenaere: Ah just seen it :) - I suppose it could be closed and a new task could be opened for seeking, but I wanted to keep all the code in one task. Or create separate dependent tasks ? 15.41.32 # mt: ah ok, forgot about the seeking part :) 15.41.41 # * mcuelenaere just thought your forgot to close it :) 15.42.33 # mt: You should at least add a comment to say that parts have been committed - I hadn't noticed... 15.43.12 Quit timc (Read error: 110 (Connection timed out)) 15.44.50 Quit kugel (Remote closed the connection) 15.46.15 # linuxstb: ok sure. I hadn't added a comment because I thought I'd just say that in the next weekly update and on the wiki. 15.47.13 # mt: The task should be self-contained. People won't know to look in other places for info about it. 15.48.00 # Yes. I'll just wait till I'm home to upload the relevant patch and then comment on it. 15.48.37 Join timc [0] (n=aoeu@c-68-45-191-214.hsd1.pa.comcast.net) 15.50.27 # What patch? 15.52.21 # linuxstb: The last patch in the task wasn't the one committed, there were some modifications after that .. 15.52.38 # mt: hmm seems my target starts crashing whenever I put a .rm file on it 15.52.45 # probably metadata parser choking on it 15.53.13 # mcuelenaere: What target do you have ? 15.53.21 # mt: Onda VX747 (MIPS) 15.53.46 # hmm .. I'll check it when I get back home. 15.53.48 # mt: That's OK - just post a comment saying "a modified version of the above patch was committed as r21695" 15.54.11 # linuxstb: okay, will do :) 15.56.36 # mt: error is in metadata_common.o -> read_uint32be 15.57.05 # 18: 8e040000 lw a0,0(s0) -> probably an unaligned access 15.57.12 # mcuelenaere: Could I reproduce that in the sim ? 15.57.24 # Oh, I think no :) 15.57.27 # don't think so 15.57.36 # I just read this in the forums: "Editing ID3 tags with more than one line visible would be really cool too." (http://forums.rockbox.org/index.php?topic=3030.msg21460#msg21460) Is there a tag editor in Rockbox already ? 15.58.46 # the code tries to acces 0x80151BE2 15.58.48 Quit kachna|lappy (Read error: 110 (Connection timed out)) 16.01.32 Part sakuramboo 16.03.10 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 16.07.11 Quit linuxstb (Remote closed the connection) 16.09.30 # mcuelenaere: Do you have other targets to test on ? 16.09.35 # this seems odd... iriver_flash uses the 1st 8 words from the flash image as the reset vector, an address well into the program space 16.09.46 # mt: nope 16.09.50 # the IriverFlashing page says the original reset vector is 0x8, which is in the flash space 16.09.55 # how does this work? 16.10.03 # mt: I inlined read_uint32be() and the unaligned access is in get_rm_metadata 16.10.56 # ReKleSS: the OF runs directly from flash, and so does rockbox ROM image too 16.11.39 # but at init, isn't the address it points to unconfigured? 16.11.39 # mcuelenaere: I think the problem could be in rm_parse_header (it's in get_rm_metadata) 16.11.45 # it's right after the rm_parse_header() call 16.11.48 Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) 16.12.34 # mt: if you understand MIPS assembly: http://pastie.org/538573 16.12.52 # (line 93) 16.13.05 # the way I read the MCF5249 datasheet the only accessible memory is whatever's connected to CS0, the flash 16.13.46 # hum, that looks weird 16.13.52 # ReKleSS: what do you mean with that? on hardware init, the CPU reads the reset vector stored in flash at 0x0 (including the reset vector and stack address). And the iriver firmware has a fixed entry point at 0x8 that's where the default reset vector points to 16.14.50 # yes, but the reset vector in bootloader.iriver is 0x10003EA0, which isn't in the flash 16.20.12 Join mt__ [0] (n=MTee@41.206.137.151) 16.20.58 # ReKleSS: are you sure that the flash does not loop there? On the gigabeat the flash is normally at 0x0, but you can access it at 0x01000000, 0x02000000 16.21.04 # bbl 16.21.11 Quit mt__ (Client Quit) 16.21.12 # I'm guessing it's something like that, I'm not sure 16.21.27 # I'm also guessing if I just write it like that it should work, but I'm curious 16.23.09 Quit rasher (Read error: 54 (Connection reset by peer)) 16.23.11 Join gregzx [0] (n=chatzill@drp22.neoplus.adsl.tpnet.pl) 16.23.14 # ReKleSS: the bootloader reset vector should be in the flash 16.23.26 # or otherwise it would be incorrect 16.24.03 Quit mt (Read error: 104 (Connection reset by peer)) 16.24.25 # be sure not to confuse between the stack location and the execution entry point 16.24.39 # stack should be in iram, and execution entry in flash 16.25.16 # ohhhhh, that's it, I'm looking at the stack pointer 16.25.20 # ok, that works now 16.25.39 # hehe, nice :) 16.26.11 # btw, last may I was the idiot who used a bootloader.iriver file with mkboot and completely messed up the bootloader... hacked together a bdm rig, should be able to finish reflashing it tomorrow 16.27.04 # ouch, you were the one. but you have build a bdm? that's great! 16.27.20 # good :) We need more people with bdm tools! 16.27.44 # err, I'd rather be able to close up my H120 and just use it, but if anything needs testing in the next little while I can do it 16.28.00 Join rasher [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) 16.28.08 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 16.28.29 # with bdm available, i would of course recommend flashing the current svn bootloader and hacking plenty with it =) 16.28.38 # does it add anything? 16.29.17 # it might fix some disk access issues with CF storage. But no other changes are known, except that it may not work at all :) 16.29.29 # heh, ok, I'll try that 16.29.44 # great :) 16.30.05 # New commit by 03kkurbjun (r21714): M:Robe 500: fix a bug where the remote LCD was not properly sleeping 16.30.15 # I have a CF adaptor here too, and a somewhat dodge 32gb CF card 16.31.16 # oh, that's great. If possible, you should really give it a try with CF to see if that works. Then it would be a good point for a new bootloader release 16.31.31 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 16.32.14 # mt: it crashes at read_uint32be(fd, &rmctx->bit_rate); /*avg bitrate*/ in case FOURCC('P','R','O','P'): 16.34.30 # mt: replacing line 422 with RMContext *rmctx = (RMContext*) ((int)id3->id3v2buf &~ 3); seems to work 16.37.16 # hmm getting codec failure's though 16.37.24 # mcuelenaere: Doesn't that round the address down? 16.37.35 # yes I know, it's not good 16.37.46 # but at least it makes the unaligned access go away :) 16.38.01 # ;) 16.38.11 # Just add 3 first should be OK 16.40.22 # Gentlemen and ladies, PDBox makes sound on-target! 16.40.42 # \☺/ 16.40.44 Quit patmulchrone (Read error: 60 (Operation timed out)) 16.40.52 # is it the expected sound? ;) 16.40.59 # :-D Yes! 16.41.05 Join patmulchrone [0] (n=pat@99.13.70.2) 16.41.19 # Pure and simple sine of 220 Hz. 16.41.31 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 16.41.46 # Good news 16.42.38 # I'll do a clean (without debugging info) patch later in the evening. 16.47.29 # mcuelenaere: in file_get_contents() in helloworld.lua, io.open(filename, "r") returns a userdata that is not nil even if the file doesn't exist. (1) this shouldn't according to http://www.lua.org/pil/21.2.html (2) How can we know io.open didn't find the file at the moment ? 16.48.17 # 1) will fix 2) look in the source ;) 16.48.58 # Grahack1: currently it does if(!rb->file_exists(filename)) flags |= O_CREAT; 16.49.05 # so if the file doesn't exist, it makes it 16.51.31 # even in "read" mode ? 16.51.53 # GodEater: my ipod goes wrong witn 9702 in basically exactly the same way as horscht's does 16.52.25 # GodEater: so i'm inclined to believe it's relevant despite the large number of patches i have. i also like to think i'm qualified to judge whether they're relevant :) 16.52.36 # er, 9708 16.52.45 # i was going to do a build with just 9708 but I've not gotten around to it yet 16.52.51 # it's too much effort to narrow it down :) 16.53.44 # It is always good to check however 16.53.45 # Grahack1: yes, but fixed now 16.53.51 # AlexP: yah, i am intending to do so 16.53.56 # Things can have unexpected consequences :) 16.54.00 Nick AlexP is now known as AlexP_ (n=alex@rockbox/staff/AlexP) 16.54.01 # i just haven't found the time yet, i've not changed the build on my ipod for a while 16.54.02 Nick AlexP_ is now known as AlexP (n=alex@rockbox/staff/AlexP) 16.54.14 # i am fairly careful about how i do it though 16.54.24 # i use it for many hours between adding patches :) 16.54.26 *** Saving seen data "./dancer.seen" 16.54.37 # and have playlists saved for testing with many different codecs interleaved etc :) 16.54.43 # New commit by 03mcuelenaere (r21715): Lua IOlib: don't create files when they don't exist 16.55.34 # mcuelenaere: What does that mean? 16.56.14 # linuxstb: when opening files in Lua, if they didn't exist, they got created 16.56.23 # if i wrote a proper patch for tools/version.sh that lets it work with bzr-svn repos as well as git-svn, would anyone care? :) 16.56.32 # mcuelenaere: That's not what the commit message said ;) 16.56.49 # heh, /me expects people to read the the diff ;) 16.58.17 # The diff doesn't help much either (without more context)... 17.00.03 # New commit by 03mcuelenaere (r21716): RM metadata parser: fix unaligned access 17.00.54 # Torne: What do you think? ;) 17.01.15 # ? 17.01.45 # Torne: About whether anyone would care about supporting bzr-svn in tools/version.sh... 17.02.35 # * linuxstb is probably being too cynical about his fellow rockbox devs 17.02.43 # heh 17.02.57 # * Torne just doesn't like git. :) 17.04.06 Quit jfc^2 (Read error: 54 (Connection reset by peer)) 17.04.29 Join jfc^2 [0] (n=john@dpc691978010.direcpc.com) 17.11.51 Join mt [0] (n=MTee@41.233.150.185) 17.13.16 Quit patmulchrone (Read error: 110 (Connection timed out)) 17.13.17 # mt: about what you mentioned earlier today, would it be possible to have the .rm parser descramble AC3 files in .RM ? 17.14.12 # mcuelenaere: Thanks for the fix. :) 17.14.23 # np 17.14.32 # mt: I didn't get the codec working though 17.16.03 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 17.16.52 # is MIPS big endian then? 17.17.09 # little endian 17.17.12 # at least this one is 17.17.37 Join n1s [0] (n=n1s@rockbox/developer/n1s) 17.17.43 # saratoga : Maybe, but AC3 will still have to go through a different path. 17.18.20 # mt: how do you want to do handle it? 17.18.44 Join patmulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) 17.19.54 # I'll need to add a flag_rm for ac3context (or whatever its struct is) , that whenever asserted the codec will go through a different code path .. That's one solution. 17.20.34 # mcuelenaere: Let me test on my dap .. 17.21.20 # mt: I only tried http://samples.mplayerhq.hu/real/AC-cook/FUN_RM_96.rm , I'll try some others too 17.22.14 # mcuelenaere: It's crashing in cook.codec ? i.e get_rm_metadata finishes properly then the codec fails ? 17.22.30 # mt: yes, but it doesn't crash; it gives a codec failure 17.23.43 Join Strife89 [0] (n=Michael@adsl-154-19-202.mcn.bellsouth.net) 17.24.45 # RMContext is memcpy'd back from id3v2buf in cook.c ( init_rm() ), so my first guess would be that values aren't loaded correctly into rmctx since memcpy'ing didn't account for the change you did in the parser .. 17.26.25 # ah 17.29.02 # mt: right, that does make it work :) 17.29.22 # \o/ 17.29.29 # shall I commit or will you? 17.29.47 Quit flydutch ("/* empty */") 17.30.04 # It would be faster if you committed. :) 17.31.38 # New commit by 03mcuelenaere (r21717): Cook codec: make sure the RMContext get aligned correctly, or we won't be able to find it 17.32.40 # saratoga: What do you mean by "having the rm parser descramble AC3 files"? Won't it just work the same as other multi-format containers (vorbis/speex in Ogg, aac/alac in MP4, etc)? 17.33.42 Quit lucent (Read error: 110 (Connection timed out)) 17.33.54 # Torne: I expect no-one to care in a good way, i.e. so long as your patch extends the functionality without breaking it, no-one will mind if you want to add bzr-svn support. 17.34.03 Quit ReKleSS ("Leaving") 17.34.45 # Torne: and while I respect your ability to tell if a patch is okay to comment on with other patches involved in your build too - it does set rather a double standard, since we ask most contributors to only test with one patch applied at a time =/ 17.38.34 # linuxstb: isn't it a little different though since you can have a both different containers for AC3 and different codecs for RM [for example]? 17.38.34 Quit patmulchrone (Read error: 110 (Connection timed out)) 17.38.43 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 17.40.03 # i was hoping we could preprocess the file enough during parsing that liba52 doesn't need to be changed 17.40.09 # saratoga: No - we just have "a52.codec" and "a52_in_rm.codec", which both link to liba52. 17.40.09 # Or at least, that's how I imagined it working. Similarly for "mp3_in_rm" 17.40.49 # liba52 shouldn't need changing. 17.41.32 # linuxstb: I thought of something like a52_in_rm.codec but never thought it would be acceptable. :) (This should be easier than what I suggested first) 17.42.12 # mt: As I said, that's how other codecs work. I don't see the fact that we have an "a52_in_nothing" codec as affecting that - disk space is cheap... 17.45.18 # Fine. I'll work on seeking first though. 17.48.51 # GodEater: yah, I was intending to do so, I was just reporting my findings while I had found them, since I didn't have time at the time to retest with just the one :) 17.50.02 # i have since not been bothered enough to actually do it, but i did intend to at the time. :) 17.50.51 Join BryanJacobs [0] (n=bryanjac@e33.cs.rochester.edu) 17.52.46 # BryanJacobs: Hi. How are things going? 17.54.00 # grr, kbd_input() changes font and doesn't set it back :( 17.56.05 # BryanJacobs: Would you be able to start posting patches to flyspray, rather than your own site? That way they'll get more exposure and can be commented on properly. I remember pondlife already suggesting this a while ago... 17.57.25 # * AlexP wasn't aware that there had been patches posted 17.57.26 Quit jordan` (Read error: 110 (Connection timed out)) 17.57.50 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 18.05.52 Join JdGordon| [0] (i=ae913eb6@gateway/web/freenode/x-57377b5ef9200ff3) 18.13.59 Quit gregzx ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 18.25.23 # * linuxstb wonders why a bootloader branch was created... 18.27.44 Quit mt (Read error: 104 (Connection reset by peer)) 18.28.08 Join captainkwel [0] (i=2669ecc2@gateway/web/freenode/x-d132cc35df23863d) 18.28.43 # does the git branch of rockbox have some kind of .gitignore file in it? 18.28.59 # (also why must every bloody vcs have ignores in a different format and location) 18.30.26 # to keep everyone on their toes 18.31.01 # * linuxstb is also not following the "portalplayer bootloader versions" thread - just do "make VERSION=xxx"... 18.31.10 Quit Grahack1 ("Leaving.") 18.31.38 Quit r0b- (Read error: 60 (Operation timed out)) 18.31.44 Join r0b- [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) 18.32.02 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 18.32.40 Quit desowin (Read error: 113 (No route to host)) 18.36.28 Quit JdGordon| (Ping timeout: 180 seconds) 18.39.47 Join mt [0] (n=mt@41.233.150.185) 18.45.35 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-720ad27aae6f5e10) 18.48.43 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 18.48.58 Join courtc_ [0] (n=court@unaffiliated/courtc) 18.49.49 Quit courtc (Nick collision from services.) 18.49.51 # Does FS#10210 need anything more? 18.50.01 Nick courtc_ is now known as courtc (n=court@unaffiliated/courtc) 18.53.26 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 18.53.38 # Hillshum: Looks non-controversial to me - I'm surprised no e200 owner has complained before... (I don't own one) 18.54.07 # * Hillshum hopes they don't complain after it gets committed 18.54.29 # the gigabeat does it already right? 18.54.30 *** Saving seen data "./dancer.seen" 18.54.56 # Yes, I just looked at the keymaps now. 18.55.23 # Do we have any other rotated targets? 18.55.48 # Wait, the Fuze doesn't need to be rotated 18.56.23 # Correct... 18.57.07 # * mcuelenaere wonders why nobody yelled about the yellow.. 18.57.18 # Yellow! 18.58.22 Join patmulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) 18.58.49 # I've never played a film on my e200, but that change seems a no-discussion one to me 18.58.53 # Should go in :) 18.59.08 # FS#10210 that is 18.59.12 # anyone with a 64-bit pc willing to test this patch for me? http://pastie.org/538780 18.59.22 # So we just need a committer ... 18.59.27 # I've never tried to watch any video on the e200 18.59.41 # bertrik: Hmmm, I don't see any around :) 19.00.20 # philips sa9200 would benefit too, off the top of my head 19.00.30 # dunno that mpegplayer is even working on that yet 19.01.28 # ok, I will test and commit FS#10210 19.01.49 # cool 19.02.19 Quit amiconn (Remote closed the connection) 19.02.19 Quit pixelma (Remote closed the connection) 19.04.01 Join pixelma [50] (n=pixelma@rockbox/staff/pixelma) 19.04.03 Join amiconn [50] (n=jens@rockbox/developer/amiconn) 19.05.16 # linxstb: ok, I'll post this week's work on Flyspray - I just felt that something that wasn't ready for widespread consumption shouldn't have gone there 19.05.51 # 'm almost done with multifile buffering 19.09.56 # I don't really understand why the buffering was implemented as a ring anyhow... there's a lot of code in here just handling the case for "ok, my stuff crosses over the end of the buffer, what do I do now?" 19.10.40 Join Lear [0] (i=chatzill@rockbox/developer/lear) 19.11.45 # I should add the patch creator to docs/CREDITS, right? 19.12.05 # yes, if it isn't already in there 19.14.33 Join Ubuntuxer [0] (n=johannes@dslb-094-221-081-051.pools.arcor-ip.net) 19.15.45 # New commit by 03bertrik (r21718): Accept FS#10210: "Mpegplayer playback controls on portrait oriented players" by Matthew Bonnett. 19.15.55 # how would I find my c250 in the terminal on a Mac (currently in OF USB since it wouldn't connect using Rockbox USB)? 19.16.22 # pixelma: is it in /Volumes ? 19.16.37 # also try disk utility 19.16.41 # I'd like to help finding out a bit more but I have no idea about Macs... 19.17.15 # Hillshum: sorry, no idea... you have to be very patient with me 19.17.36 Quit petur ("work->home") 19.17.49 # Torne: I've been using your USB-charging patch and my 5.5G works with everything I've plugged it into 19.18.06 # pixelma: It should be mounted in /Volumes/ 19.18.31 # which means for me? 19.19.02 # New commit by 03mcuelenaere (r21719): Try at fixing 'cast to/from pointer to/from integer of different size' warnings 19.19.19 # * pixelma isn't sure this is going anywhere :/ 19.19.25 # pixelma: run "ls -l /Volumes/" in a terminal 19.20.50 # yes, I see a SANSA_C250 there, where do I go from here? 19.21.58 # cd /Volumes/SANSA_C50 19.39.16 # What happened to the Tester badges? 19.39.47 # Hillshum: You'll have to bother scorche about that. 19.40.25 # BryanJacobs: ring buffer is logical for buffering because... umm.. it just is :p 19.40.29 # What tester badges? 19.40.39 # who else would you want to do it? 19.41.11 # JdGordon: was that supposed to be "how"? 19.41.15 # AlexP: Wasn't the idea thrown around at devcon? 19.41.18 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 19.41.22 # BryanJacobs: yes :p 19.41.30 # Hillshum: Perhaps, I can't remember 19.41.39 Join Blue_Dude [0] (n=chatzill@64.25.25.6) 19.41.41 # Hillshum: I have no idea how you would set down criteria for that 19.41.44 # the way I'm implementing it is as a set of allocated spaces which may be contiguous but sometimes aren't 19.42.03 # sized how? 19.42.21 # starting with constant size and chained together 19.42.40 # New commit by 03Ubuntuxer (r21720): new game plugin for colored players named clix (by Rene Peinthor) 19.42.40 # as in, you can have a 128k allocation be four 32k chunks 19.43.14 # if space is available and things aren't freed immediately we can expand a chunk 19.44.09 # Ubuntuxer, is this patch the one from FS#8925? 19.44.14 # this lets multiple files play nicely together :-) 19.44.17 # BryanJacobs: Isn't that going to just result in fragmentation, ending up with every request for 32KB of data by a codec needing the buffering code to do some copying? (remember the 32KB can be anywhere within the file) 19.44.19 # yes 19.44.31 # linuxstb: fragmentation, yes, copying, no 19.44.54 # BryanJacobs: So what happens if the file is fragmented, and the codec wants 32KB of data, split across fragments? 19.45.28 # linuxstb: ok, in that case you either need copying or duplication 19.45.35 # Ubuntuxer, please put the FS# in the commit message next time 19.45.42 # but the current codecs don't seem to do that much... 19.45.51 # BryanJacobs: They do... 19.45.52 # if you only use advance_buffer that doesn't happen at all in fact 19.45.54 # I forgot it, sorry 19.46.00 # I'm not considering seeking yet 19.46.05 # Ubuntuxer: New game? :) 19.46.12 # BryanJacobs: Nor am I.... 19.46.29 # yes, but just for colored players 19.46.34 # * BryanJacobs has been using the wavpack codec as a reference 19.46.43 # it only makes use of two or three buffering calls 19.46.52 # and only reads forward in the file unless you seek 19.47.06 # BryanJacobs: That's probably a bad example, as it's not using the buffering API as efficiently as other codecs... 19.47.12 # hm. 19.47.12 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 19.47.13 # IIRC, it's using read() ? 19.47.41 # it was using read in the PC version; in Rockbox it uses codec_advance_buffer 19.47.54 # OK, let me have a quick look at it... 19.48.36 # besides, we should only really have to copy occasionally 19.48.41 # BryanJacobs: It seems to be using read_filebuf() 19.48.52 # into its own local buffers 19.48.53 # one sec... 19.48.54 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 19.49.03 # * BryanJacobs goes to fetch original source code 19.50.08 # actually, look at it like this 19.50.14 # if there's only one file in the buffer 19.50.23 Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 19.50.24 # then there'll always be space after the current handle to expand it 19.50.27 # right? 19.50.49 # Not if that file was loaded whilst there was other data in the buffer. 19.50.54 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 19.51.07 # its handle will be added after that other data 19.51.10 # Sorry, ignore that, I don't think I understood your question... 19.51.22 # so, the buffer will look like: 19.51.25 # I'm talking about things getting fragmented... 19.51.29 # OTHERDATA -> mydata 19.51.36 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 19.51.48 # All right. I'm losing my mind here. I can't get a E200 sim to compile. I've tried a fresh checkout. I've tried reinstalling cygwin. It breaks on apps/codecs/libcook/bitstream.h every time. 19.51.55 # now, in the case we're only buffering one file, it will go to -> mydata -> OTHERDATA -> mydata and then to just mydata 19.52.07 # Blue_Dude: That's very possible - it's a new commit... 19.52.23 # so, there won't be any fragmentation in the single-file case 19.52.39 # in the multi-file case it can arise, yes 19.52.42 # But it's a few days old. Why isn't it breaking in the daily build? 19.52.45 Join tessarakt [0] (n=jens@e180079183.adsl.alicedsl.de) 19.52.52 # Blue_Dude: Because the daily builds don't use cygwin... 19.52.55 # Blue_Dude: those aren't build with cygwin 19.53.09 # Um. Hm. now what? Revert? 19.53.19 # Ups, I forgot the keymap for the h300 in clix, I'll fix this... 19.53.22 # BryanJacobs: But the multi-file case is the most common - Rockbox almost always has more than one file buffered. 19.53.38 # no, I don't mean two files buffered serially 19.53.51 # in the original buffering code it "finishes" the old file before starting the new one 19.53.58 # here, let me get you a source line 19.54.02 # Blue_Dude: how exactly does it breaks? 19.54.07 # Blue_Dude: try the next to latest commit (svn update rockbox -r ) 19.54.08 # linuxstb: I'm gonna post a bug report in FS. Then I guess roll it back. 19.54.33 Quit Hillshum (Client Quit) 19.54.36 # Hillshum: it's been breaking since yesterday. It's not just the latest. 19.55.49 # ok, updated to r21718 to make sure it's not an old bug that's already fixed but using RockboxUSB on that Mac here doesn't automatically show me the volume - in OF USB it does. The USB screen itself is shown but nothing happens, sometimes Rockbox even hangs on that screen if I pull the cable again 19.55.51 # Blue_Dude, I'll try to build an e200 sim and see what happens 19.56.01 # mcuelenaere: It says, and I quote: [....]/apps/codecs/libcook.a(bitstream.o): in function 'put_bits': 19.56.07 # any idea what I could try and check? 19.56.25 # BryanJacobs: So you're saying that your patch doesn't modify the existing buffering behaviour (for "normal" codecs)? 19.56.29 # Blue_Dude: only that line? 19.56.42 # linuxstb: buffering.c line 236 19.56.43 # as I said though - I don't know a lot about Macs... 19.57.05 # mcuelenaere: [....]/apps/codecs/libcook/bitstream.h:196: undefined reference to '___assert' 19.57.15 # linuxstb: no, it does modify the behavior, I was just trying to say that no more copying should occur with my patch in the "normal" case than did before 19.57.34 # Yes there are *three* underscores, not two like you'd think. 19.57.53 # BryanJacobs: So it's still treated as a single ringbuffer for normal files? 19.57.56 # Blue_Dude: try #ifndef CYGWIN 19.58.05 # In that file? 19.58.12 # eh, __CYGWIN__ 19.58.13 # linuxstb: yes, the only difference is that it won't ACTUALLY allow overwriting other people's data 19.58.18 # no, around the assert() calls 19.58.19 Join saratogalab [0] (n=9803c264@gateway/web/cgi-irc/labb.contactor.se/x-7d1a5c883081427c) 19.58.36 # BryanJacobs: What do you mean? 19.58.38 # see buffering.c line 619 19.58.43 # where the allocation is cut short 19.58.44 # you could just comment out the assert calls 19.58.56 # in my code it would cause fragmentation instead 19.58.57 # Blue_Dude: or better, do #ifdef __CYGWIN__ #define assert #endif 19.58.58 # they shouldn't do anything 19.59.10 # BryanJacobs: Hmm, that's an odd comment... " /* This would read into the next handle, this is broken */" 19.59.19 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 19.59.21 # it's a correct comment... 19.59.24 # mcuelenaere: I have an idea. The current include in that file is #include . Would #include "assert.h" work better? 19.59.44 # this means someone has requested more data than can be immediately buffered contiguously into the current handle 19.59.45 # I don't know, does Rockbox has its own assert.h file? 19.59.56 # havE* 20.00.00 # mcuelenaere: There one in firmware/include 20.00.00 # so it doesn't buffer as much as they asked for 20.00.02 # BryanJacobs: it's not *my* charging patch, but i am nonetheless glad that it works for you :) 20.00.22 # * shotofadds is listening to music from an SD card on his D2... :o) 20.00.38 # Yay! 20.00.38 # :) 20.00.38 # in my code, it instead tries to find space between some of the handles in the list 20.00.40 # congrats :) 20.00.51 # BryanJacobs: Hmm, well that shouldn't happen in practice. Or does it? 20.00.52 # gevaerts: and I'm not even using the OF... 20.01.09 # linuxstb: no, that code on line 619 shouldn't happen in practice, that would be bad 20.01.21 # shotofadds: I know. You wouldn't do something horrible like talking about using the OF in #rockbox :) 20.01.29 # "Try to recover by truncating this file" x_x 20.01.48 # gevaerts: what's the status of your storage rework? 20.01.51 # if that line ever happens you won't ever get the rest of the file into the buffer without reopening it 20.02.15 # Rockbox USB, MacOS anyone? If not... I'd also rather leave now (it's a working place)... 20.02.16 # * shotofadds compiles a build with tagcache and pictureflow, just to have a look.... 20.02.23 # * mcuelenaere is interested in gevaerts' storage rework too 20.02.30 # mcuelenaere: Aha. The cygwin assert.h has a condition that _cplusplus be defined before it'll work. The firmware/include doesn't have that. 20.02.39 # BryanJacobs: That looks like a corner case that shouldn't need handling - i.e. the request should return a "TOO LARGE REQUEST" error message, and nothing should be buffered as a result of it. 20.03.04 # linuxstb: but it'll happen occasionally and expectedly in the new code... 20.03.15 # Blue_Dude: so changing it to "assert.h" works? 20.03.24 # example buffer layout: FILE1 FILE1 FILE1 FILE2 EMPTY EMPTY EMPTY 20.03.26 # mcuelenaere: Dunno yet. I'm trying it now. 20.03.31 # shotofadds, that's a new feature for the D2? 20.03.38 # that'll cause it to happen if the user requests more FILE1 to be buffered 20.03.54 # that same file is included in wma, i'm pretty sure we just commented out the asserts 20.04.03 # bertrik: yeah, since we had a read-only filesystem until now... 20.04.12 # what I want the result to look like: FILE1 FILE1 FILE1 FILE2 FILE1 EMPTY EMPTY 20.04.40 # so the D2 port is getting closer to be usable? 20.04.47 # BryanJacobs: So have you rejected the idea of having a wavpack-specific file loader that interleaves the data at buffering time? 20.04.50 # mcuelenaere: Rock and roll. There it goes. 20.04.57 # mcuelenaere: Works. 20.05.11 # linuxstb: I can still do that. Would you prefer that I abandon this and do that instead? 20.05.16 # ok, I'll commit that then 20.05.23 # it's just so... domain-specific 20.05.47 # actually, I might even be able to finish an interleaved loader this week 20.05.47 # * JdGordon| doesnt care what happens as long as buffering/playback gets simpler instead of more complicated :p 20.05.56 # mcuelenaere: It's the #include in the libcook/bitstream.h file. 20.05.58 # JdGordon: but it will get simpler! 20.06.05 # pixelma: there are still usability issues with the touchscreen in certain situations, but it's getting there now 20.06.06 # New commit by 03zagor (r21721): Mother now runs svn instead of the children, to avoid killing it. Svn update is only ran wheen needed. Remove build tree centrally. 20.06.07 # Blue_Dude: I know 20.06.22 # mcuelenaere: OK, just so we're on the same page. :) 20.06.27 # linuxstb: the interleaved loader is much easier to do 20.06.34 # shotofadds: congrats! :) 20.06.35 # BryanJacobs: For once I agree with JdGordon| - a simpler buffering system would be nice... 20.06.41 # New commit by 03mcuelenaere (r21722): Fix compiling on Cygwin hosts. 20.06.56 # * BryanJacobs thought the current buffering system was complicated, it took him nearly a week to learn it properly 20.07.12 # pixelma: One big caveat though, the only way users will be save settings etc is if the SD drive becomes the primary drive - ie. you need a card inserted to boot Rockbox :/ 20.07.21 # *be able to 20.07.36 # I'm sure the idea of a more statically allocated buffering thingy was brought up before... isnt it harder to keep track of the blocks than a ring? 20.07.42 # mcuelenaere: Hang on. Hung up again later. I'm restarting a clean build to fix dependencies. 20.08.05 # JdGordon: for simplicity I currently use a sorted linked list 20.08.10 # and insert-in-order to keep it going 20.08.15 # mcuelenaere: It went past the previous section and stopped later. Same error. 20.08.30 # Blue_Dude: you sure? did make clean? 20.08.30 # BryanJacobs: If it's easy to do the interleaved loader, it might be worthwhile doing it as an experiment, so you have something to compare with your current approach. 20.08.43 # mcuelenaere: Making clean now. 20.08.46 # linuxstb: OK, I'll start on that right away then, it's much easier to finish 20.08.53 # Ubuntuxer: yellow! 20.09.10 # * mcuelenaere thinks we need a yellow-shouting bot 20.09.18 # the only issue is getting the right code into the buffering thread 20.09.27 # BryanJacobs: But I also don't want to discourage you from improving the more general Rockbox buffering code... ;) 20.09.29 # I'm in. 20.09.29 # shotofadds: You could make rockbox save settings etc on the sd card even if rockbox itself is installed on the internal flash. But of course it would be much better to have write access to the internal storage 20.09.58 # amiconn: how would you see that working? 20.10.17 # change the .rockbox folder path... 20.10.17 # New commit by 03Ubuntuxer (r21723): add keymap for m300 and fix warnings of previous patch 20.10.17 # mcuelenaere: Is NDEBUG defined for sim builds anywhere? 20.10.22 # Just use different default paths for this... 20.10.32 # Blue_Dude: I don't know what NDEBUG does.. 20.10.58 # mcuelenaere: Me either. But it voids the assert declaration if it's defined. 20.11.01 # BryanJacobs: I was thinking that you could do something like add a function pointer in the id3 struct which would by default be the current buffering code. The wavpack metadata parser would change this to the wavpack-hybrid loader if it found a correction file. 20.11.23 # BryanJacobs: But I've no knowledge of the internals of the buffering code - just how it works from a codec's point of view. 20.11.29 # * mcuelenaere thinks we should go with saratoga's advice and comment the asserts() out 20.11.47 # linuxstb: the issue is that the previous/next files could be buffering too... 20.11.53 # mcuelenaere: Right there with you. Let's see if the clean build works forst. 20.11.55 # first 20.12.12 # BryanJacobs: How? I thought there was just a single buffering thread, buffering files sequentially. 20.12.23 # mcuelenaere: Or just delete them? 20.12.34 # it allocates the SPACE sequentially 20.12.40 # linuxstb: perhaps they're usefull for debugging purposes? 20.12.42 # BryanJacobs: one thing you may have overlooked... I tihnk its only the actual file that can be broken up in the buffer.. other stuff like its AA or metadata needs to be sequential 20.13.05 # JdGordon: easy to do by making a handle whose size is the whole needed size 20.13.22 # I've only been fragmenting audio data so far 20.13.37 # linuxstb: there are two threads working 20.13.47 # there's the actual buffering thread, which loads the data 20.14.02 # and then the other one which does things like allocating handles and requesting buffering stuff 20.14.34 # the issue is when the wavpack-specific code would be invoked - it would have to be from the buffering thread 20.14.45 # Yes, so why is that a problem? 20.14.46 # and ONLY when inside a wavpack-type handle 20.15.06 # so, that means buffering needs to know about the file type, which means that it can't just be a modification to struct mp3info 20.15.20 # Is a handle a struct? 20.15.33 # yes, that's where I'd put the callback 20.15.42 # struct memory_handle 20.15.51 Join jordan` [0] (i=gromit@78.235.252.137) 20.17.09 # mcuelenaere: frak. Broke again. 20.17.21 # * amiconn doesn't really understand how multi-file buffering could work at all 20.17.23 # Blue_Dude: huh, with the asserts commented out? 20.17.44 # mcuelenaere: No. Clean build with "assert.h" 20.17.50 # amiconn: take a look at my preliminary patch... 20.18.26 # Afaiu the buffering thread would need to know the relation between the two files. Both might be larger than the total available ram 20.18.27 # BryanJacobs: are you thinking of a max and min size blocks? or when a handle is requested if its smaller than the space free, that space just gets split into two new blocks? 20.18.50 # JdGordon: I was thinking of a max size, no real min 20.19.02 # so that when someone asks for 128k they get 4x32k 20.19.37 # I wasn't worried about little bitty bits going to waste if people ask for 31k at a time 20.20.01 # and if someone keeps requesting 4k? 20.20.06 # or less 20.20.13 # then they'll get a chain of 4k -> 4k -> 4k 20.20.26 # or actually 20.20.36 # if there's room it can be their first handle gets grown 20.20.54 # so they get a 4k handle, then it becomes 8k, then 16k, and so on 20.20.59 # err 12 20.21.01 # I can add really 20.21.23 # see, it doesnt sound any less complicated, and sounds more prone to fragmentation and wasted ram? 20.21.28 # * BryanJacobs thinks perhaps he should make a diagram 20.21.35 # probably :) 20.21.45 # no, there's no fragmentation at all in the current use cases 20.22.10 # the ONLY time there'd be fragmentation is if you interleave buffering calls AND you don't free things promptly 20.22.30 # there almost has to be after a while of buffering and freeing... 20.22.34 # bbs 20.22.37 # BryanJacobs: With the typical (I think) example of a 4MB .wv, 30MB correction file and 28MB audio buffer, how would the buffering work? 20.22.47 # linuxstb: interleaved or multifile? 20.23.09 # I mean, which buffering system are we talking about here? 20.23.17 # BryanJacobs: With your patch - which is that? 20.23.27 # multifile 20.24.05 # mcuelenaere: Assert is just a DEBUGF type message, I guess? Well, it compiled with out them. Total of 5 lines commented out. 20.24.06 # with my patch, the 4MB .wv is buffered sequentially and the 30MB correction file makes space around it 20.24.20 # So what if the .wv is larger than the buffer? 20.24.30 # only one chunk of the .wv is used at a time 20.24.39 # unless a CHUNK is larger than the buffer we're OK 20.24.59 # and only 4k of the chunk is used in one go in the optimized code 20.25.12 # What about a 20MB .wv and a 160MB correction file on a 16MB target (12MB audio buffer)? 20.25.27 # * linuxstb thinks we need pictures, with colours indicating different things in the buffer... 20.25.50 # * BryanJacobs agrees with linuxstb - the picture is clear in BryanJacobs' head but difficult to explain without a whiteboard 20.25.56 # Blue_Dude: so with http://pastie.org/538923 it compiled correctly? 20.26.10 # * Torne also thinks you need to specifically cover the case where the current playing file is an mp3 and thus the wavpack codec is not running yet, i.e. the buffering code is just getting it buffered up in advance :) 20.26.21 # Anyone knowledgeable about cpu_boost() here? 20.26.32 # how about I do the codec-specific buffering quickly this week and then start illustrating what my buffering modification would do so people can understand it 20.26.52 # BryanJacobs: I guess my main questions are simply whether your proposal a) changes anything for existing codecs; b) cleanly deals with files larger than the audio buffer. 20.26.58 # mcuelenaere: Yeah. Except I commented out the #include also. 20.27.11 # linuxstb: the answers are yes and yes, but for a) they won't notice :-) 20.27.17 # yeah, I hesitated about that; seems like bad code style to me :) 20.27.30 # the API is still compatible and there should be no major performance losses for existing codecs 20.28.02 # New commit by 03mcuelenaere (r21724): Previous commit didn't fix compiling on Cygwin, this one should. 20.28.03 # linuxstb: And also, how does it handle seeking? 20.28.06 # BryanJacobs: So a codec that reads a variable amount of data at a time (between 0 and 32KB) won't be adversely affected? 20.28.24 # linuxstb: as long as it's the only file actively being buffered, no 20.28.41 # What do you mean by "actively being buffered"? 20.28.44 # but the usual case is that the playing file is *not* being actively buffered 20.28.54 # normally the file being played has been entirely buffered, on large mem targets 20.28.58 Quit DarkDefender (Remote closed the connection) 20.29.13 # I mean that when you call bufopen(), you're not going to call it again until you change files 20.29.14 # and if it's been buffered into non-contiguous bits of ram, what happenes if the codec then reads in variable size chunks 20.29.19 # there are so many different cases, we need pictures :-) 20.29.20 # wincent: what do you want to know? 20.29.26 # Torne: that doesn't happen! 20.29.40 # BryanJacobs: Is "bufopen()" the function called when a codec starts decoding a file? 20.29.47 # BryanJacobs: er, i'm pretty sure it does... 20.29.47 # linuxstb: yes 20.30.01 # Torne: not in the case where you have one file playing, then you open a second one 20.30.18 # and then you move on to a third after finishing with the first one 20.30.26 # they move together so there's never any interleaving 20.30.27 # BryanJacobs: i'm talking about the case where i have a playlist full of mostly mp3 or whatever, with one of your hybrid things in the middle somewhere 20.30.40 # shotofadds: multidriver will be a lot easier once I have a real target to test it :) 20.30.41 # mcuelenaere: How fast is the switching of frequency? 20.30.43 # and what the resulting change in behaviour is for the mp3 codec 20.30.49 # gevaerts: Elio! 20.30.57 # wincent: depends on the target, if it changes PLL or just a divider.. 20.31.00 # wincent: varies on different platforms 20.31.05 # Torne: oh, yeah, you'll get fragmentation there, but the mp3s will still WORK, there'll just be an occasional memcpy 20.31.11 # linuxstb: that's your drawer, not mine! 20.31.19 # gevaerts: That can be fixed ;) 20.31.24 # wincent: how fast do you want it to be? 20.31.25 # BryanJacobs: yes. that's the poitn i'm getting at: how occasional do you think occasional is? :) 20.31.37 # wincent: so you shoudnt boost/unboost too often.. 20.31.38 # linuxstb: I still think that pondlife is a better victim :) 20.31.48 # Torne: it's a function of the amount of RAM available and how much data the codec needs at once 20.31.59 # if the codec prompty frees everything it uses, that should NEVER happen 20.32.19 # hm? how does the codec freeing anything have anything to do with it? 20.32.20 # if the codec hangs on to old portions of the file, it will eventually happen unless the buffer is very large relative to the file 20.32.29 Join Blue_Dude_ [0] (n=chatzill@64.25.25.6) 20.32.33 # i'm talking about the case where teh mp3 has been completely buffered into ram before playback of it even starts 20.32.46 # but it was buffered into several noncontiguous reginos, because of the previous effect of your codec 20.32.58 # if the codec frees old space, the hybrid stuff will go in there instead of in "front" of the mp3 20.33.25 # if the hybrid codec frees its space efficiently, the mp3 won't need to be buffered noncontiguously in the first place 20.33.27 # In PDBox I make the calculations in the main loop, so I thought it could need some additional processing power. 20.33.40 # BryanJacobs: How does the buffering code know how to share the RAM between files 1 and 2 (i.e. .wv and .wvc? 20.34.02 # wincent: what target do you have? 20.34.12 # BryanJacobs: so your assumption is that the malloc/free behaviour of the multifile-using codec is going to usually be nice and sequential and thus ram will be unlikely to get fragmented in the first place, yes? 20.34.24 # mcuelenaere: iriver H320 20.34.36 # linuxstb: in the case of a codec-specific interleaving loader it can just load a certain both block headers and then the ratio can be arbitrary 20.34.48 # Torne: yes 20.34.49 # But now, as PDBox works with the most simple test, we will see whether CPU boost is needed. 20.35.02 # BryanJacobs: Sorry, I'm still talking about your "generic" multifile buffering. 20.35.28 # BryanJacobs: then why not use the scheme i proposed before and just revert to the normal buffering behaviour after the multifile track finishes buffering? 20.35.47 # just assume that the last place in the buffer with data from taht file in is the beginning of a normal circular buffer again? :) 20.35.48 # linuxstb: in the case of multifile buffering, it doesn't "know" - it just buffers a certain readahead of both and then requests more be buffered as the codec consumes it 20.35.58 # wincent: I would say, test it on-target and see whether cpu_boost()'ing really speeds up things (which they will I suspect) 20.36.08 # Torne: but it's the same thing! 20.36.21 # linuxstb: What I don't understand wrt multifile buffering is how buffering handles this ratio. The ratio will most certainly vary across the file, so buffering needs to know what timestamp a certain file position belongs to 20.36.33 # BryanJacobs: not if you're saying it changes behaviour for existing codecs it's not 20.36.40 # mcuelenaere: That is what I intend to do. 20.36.52 # Torne: when the multifile bits are no longer resident the behavior of the existing codecs will be identical to before 20.37.19 # when the multifile bits ARE resident, it'll be different only in that occasionally they'll have to get memmoved 20.37.27 # BryanJacobs: identical in effect, or in performance? 20.37.31 # Otherwise it may happen (for very large files and/or very small buffers) that the file positions drift further apart than the available ram size 20.37.32 # amiconn: Yes, that's why I've always thought the loader would need to be very codec-specific - interleaving bits of the two files that are decoded together. 20.37.33 # i.e. is there still overhead involved in having your code there 20.38.11 # Torne: there's some overhead but it's only because the struct memory_handle is now marginally larger and the add_handle code a bit slower 20.38.17 # there's no SIGNIFICANT overhead 20.39.06 # it does the same thing as before but in a different way 20.39.18 # different *but equivalent* way 20.39.57 # linuxstb: the loader benefits greatly from codec-specific knowledge 20.40.08 # but it's not absolutely required 20.40.49 # what I'm getting from this discussion is that I need to create a very thorough illustrated guide to how I see this working before proceeding with it 20.41.01 # is that around right? 20.41.03 # yes :) 20.41.07 # yes :-) 20.41.09 # I'd be more than glad to do that 20.41.12 # any scheme to make this work is going to be complicated 20.41.24 # I wouldn't say that... 20.41.32 Join petur [0] (n=peter@rockbox/developer/petur) 20.41.37 # the scheme itself can be simple, analyzing its behavior can be hard 20.41.38 # buffering is complicated. there are so many use-cases... so pictures surely will help. 20.41.57 Quit Ubuntuxer ("Leaving.") 20.42.10 # but before I do that I'll go with linuxstb's idea and make a Wavpack-specific buffer...er 20.42.20 # that should be quick and dirty 20.42.44 # I wonder whether it would be helpful to divide the *whole* buffer into equally sized chunks (e.g. 32KB). Iiuc mpegplayer does this. 20.43.24 # amiconn: the only thing that helps with is avoiding very small free areas, right? 20.43.30 # oh and simplifying management 20.44.00 # it avoids simplifying? ;) 20.44.07 # A chunk would never contain data from more than one file. It will waste a bit of RAM (16KB slack on average per file buffered), but it would probably simplify management a lot 20.44.13 # pixelma: :-P 20.44.15 # actually dividing it all the way doesn't have a lto of advantage, but aligning the start and end of allocated regions to some big multiple might help 20.44.44 # Torne: I was using a next* in the struct memory_handle so we didn't need alignment 20.44.48 # * amiconn is thinking about this dynamic plugin ram idea as well, which would need flexible free'ing of buffered audio data 20.44.50 # amiconn: Do you mean that files can be scattered anywhere in the audio buffer, in 32KB chunks? 20.45.04 # Yes, basically 20.45.40 # mpegplayer doesn't have to worry about the behavior of "other" codecs ;-( 20.45.46 Join webguest81 [0] (n=562d61f0@gateway/web/cgi-irc/labb.contactor.se/x-d547ae5dcb95926c) 20.45.51 # you would want the chunk size to be quite a bit bigger if you were going to do that, much larger than the maximum amount of data codecs can ask for at once 20.46.00 # to minimise the frequency with which you have to memcpy() 20.46.12 # * BryanJacobs agrees with Torne 20.46.18 # (which then means you waste more ram with slack space) 20.46.25 # That breaks (or at least, introduces memcpy's for almost every request) a lot of codecs, which request a pointer to the next 32KB of the input file, and then process N bytes of it, before advancing the file pointer N bytes and then requesting another 32KB 20.46.29 # The maximum amount of data a codec is guaranteed to get *is* 32KB (iirc) 20.46.33 # you could also just place each new file as far away from the others as possible 20.46.44 Nick J-23 is now known as J-23|away (n=zelazko@unix.net.pl) 20.46.47 # mcuelenaere: We're good. It compiles from a clean make with your update. Thanks! 20.46.51 Nick J-23|away is now known as J-23 (n=zelazko@unix.net.pl) 20.46.54 # :) 20.47.04 # amiconn: yes, the problem is when it asks for 31kb then asks for another 31kb 20.47.07 Quit Blue_Dude_ ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 20.47.08 # linuxstb: if you don't have a chunk header/footer it's OK... 20.47.11 # amiconn: when you have it in noncontiguous 32kb blocks 20.47.40 # I mean, if you know two consecutive 32k chunks have data from the same file then no memcpy is needed for a codec asking for N bytes at a time until N reaches 32k 20.47.47 Part teru ("Leaving...") 20.47.56 # I mean until sum(N)=32k 20.47.57 # The blocks shouldn't be noncontiguous by default, but optionally 20.48.05 # BryanJacobs: What about Torne's example of requesting two 31KB chunks? 20.48.17 Quit Blue_Dude (Read error: 110 (Connection timed out)) 20.48.18 # amiconn: yes, it will try its best to make them noncontiguous 20.48.26 # but it won't always be able to succeed :) 20.48.29 # linuxstb: that would require three 32k chunks in a row to pass 20.48.53 # er, to make them contiguous 20.49.13 # * BryanJacobs thinks people are catching on to what he was proposing 20.49.16 # No, and for those cases it would need to memcpy 20.49.36 # there's no way to get around having to copy *sometimes* if people require contiguous space 20.49.39 # But that shouldn't happen often. It doesn't solve the questions related to multifile buffering 20.49.40 # malloc() does that too 20.49.49 # amiconn: yes, at which point the larger the block size is, the less memcpys there are, even if the fragmentation pattern is identical 20.50.10 # Torne: Less memcpy()s perhaps, but not less data to copy 20.50.35 # amiconn: no because you know how much of a block is used 20.50.46 # at most the same amount of data is copied 20.50.50 # *are copied 20.50.58 # **number of data are copied 20.51.02 # ***sigh 20.51.08 # hahaha 20.51.13 # The default block is all-data, of course. Only slack blocks (end of file) aren't full 20.51.16 # * GodEater pats BryanJacobs gently on the shoulder 20.51.29 # The larger the blocks, the more memory is wasted 20.51.31 # (also technically small memcpys are more expensive) 20.52.41 # 32KB blocks are already quite large considering out lowmem targets 20.53.15 # who says this can't be target-specific? 20.53.27 # amiconn: sorry, i'm being too socratic. i meant that my conclusion is that keeping blocks fixed like that is probably not optimal 20.53.33 # On the swcodec lowmem targets, the audio buffer is <1MB iirc. 1MB would be just 32 32KB blocks 20.53.43 # BUFFERING_DEFAULT_FILECHUNK can be defined based on target 20.53.45 # because you want the blocks to be big really but that wastes more ram :) 20.54.21 # not having fixed blocks means you can waste very little, *if* you hav ea good enough allocationpolicy for it 20.54.32 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 20.54.33 *** Saving seen data "./dancer.seen" 20.54.56 # why don't we just take someone else's malloc implementation and change all codecs to use malloc/realloc? 20.55.16 # then it'd be pluggable 20.55.30 # wincent: congratulations for first pdbox sound :-) 20.55.30 # malloc() is not wanted in rockbox, because it doesn't make sense 20.56.00 # amiconn: ? seems to make sense to me... we're talking about allocation policies and fragmentation levels here 20.56.00 # BryanJacobs: malloc()'s allocation strategy is not optimal for normal codec, is why :) 20.56.18 # http://www.rockbox.org/twiki/bin/view/Main/WhyNoMalloc 20.56.20 # you want an allocatino strategy which under our "normal" use case behaves as close to ring buffering as possible ;) 20.56.34 # and ideally with overhead as close to ring buffering's as well :) 20.56.45 # amiconn: that does not apply 20.56.56 # normal mallocs tend to consider total heap size to be one of the parameters to minimise 20.57.10 # we have a fixed 'heap' size and thus that criteria is irrelevant 20.57.15 # amiconn: that's why there's no malloc() for things like codec memory, not why the audio buffer is not allocated using a malloc()-like 20.57.55 # Torne: why would malloc not behave like ring buffering under our normal use case? 20.58.04 # BryanJacobs: because malloc is per definition sub-optimal for a ring buffer 20.58.08 # BryanJacobs: The audio buffer is essentially a FIFO - hence the use of a ring-buffer. That's not malloc... 20.58.16 # It also applies here. malloc() is not made for the kind of allocation needed here 20.59.07 # In our own allocation scheme, blocks can be moved around if necessary. malloc pointers are fixed unless you're calling realloc() 20.59.37 # but you can't move audio blocks anyway in the current scheme 21.00.00 # * amiconn wonders whether some techniques from buflib.[ch] might be useful in the core 21.01.10 # * BryanJacobs stares in wonder at the header comment of buflib.c - can this be manna from heaven? 21.01.27 # shotofadds, do you think you'll ever be able to write the internal NAND? 21.02.19 # I'm looking into the meizus which have the 'whimory' flash translation layer and I'm starting to lose hope for it 21.02.29 # bertirk: i could physically write to the NAND now, but that wouldn't be very clever ;-) 21.02.53 # with a bit more reverse engineering, I think it's possible for the TCC FTL 21.03.15 # does the TCC FTL also do wear leveling? 21.03.30 # yes, everything's done in software 21.04.05 # I don't currently know what algorithm they are using 21.04.22 # BryanJacobs: IIRC handles can (and do) move around currently 21.05.08 # shotofadds: Do we need to use the same algorithm, or is there some kind of mapping table? 21.05.12 # If it didn't do wear leveling but just relied on error correction I could imagine that it's easier to reverse engineer 21.05.40 # we could use a different algorithm, but wouldn't that affect the wear-levelling ability overall? 21.06.03 # JdGordon: a handle is only moved when more data are requested, not when something else is growing 21.06.19 # as in, we can't grow handle B when handle A enlarges 21.06.40 # IMO the biggest problem with malloc for us is that we can't really implement free without leaking away memory to fragmentation since we have no VM in rockbox 21.07.16 # shotofadds, amiconn : have you ever seen an open-source FTL? 21.07.20 # amiconn: there is no lookup table, but it scans all physical blocks on startup, so we could potentially arrange them however we choose. 21.07.25 # saratoga: if we only used the audio buffer as the "heap" how would that be a problem? 21.07.45 # bertrik: I've never looked at one, if such a thing exists 21.07.46 # i'm not sure what you're thinking here, but without free I'm not sure how useful malloc really is 21.08.10 # saratoga: I meant that if we only store audio data using a malloc()like interface I don't see how we'd leak memory 21.08.40 # you won't provided you only ever allocate blocks of exactly one size and do not care about having memory continuous between blocks 21.08.41 # as soon as its made avialable to buffering, there will be calls to make it usable elsewhere 21.09.03 # bertrik: there are some wear-leveling filesystems, but I don't know of any translation layer 21.09.46 # for some targets we could do a complete firmware replacement (i.e. lose the OF filesystem), but that's quite a big step 21.10.20 # bertrik: that would require mtp or something similar as well 21.10.21 # for MSC we need a block device, but for MTP we could use any FS I think 21.10.47 Join Hillshum_ [0] (n=chatzill@unaffiliated/hillshum) 21.10.58 # that's also a big step, since rockbox is now exclusively FAT AFAIK 21.11.02 Quit Hillshum (Read error: 104 (Connection reset by peer)) 21.11.14 Nick Hillshum_ is now known as Hillshum (n=chatzill@unaffiliated/hillshum) 21.11.20 # JdGordon: so it shouldn't be implemented because people would want it? 21.11.45 # we *dont* want it though... you were linked the reasons 21.12.28 # I read them and, frankly, agree with them. But I think it's kind of funny to say something shouldn't be implemented because there are people who would want to (ab)use it 21.13.10 # there are FTLs in linux 21.13.16 # I think mostly these days we don't want it because it would be a massive about face, and we'd have to delete things from GoldenQuotes that used to be funny ;) 21.13.38 # I'm not completly against the idea of splitting up the entire audio buffer into 32KB blocks without the option of getting any smaller ones 21.14.00 # keeping track of them wouldnt be fun though 21.14.23 # JdGordon: like I said before, I've got an ordered linked list already 21.14.51 # they couldn't be EXACTLY 32k though unless you want to waste 32k per handle for the struct 21.15.03 # yeah 21.15.10 # Linux has FTL and NFTL and one or two others 21.15.18 # I don't think any of them are directly usable on modern MLC NAND 21.15.28 # FTL is for NOR, NFTL is for SLC NAND 21.16.31 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 21.16.39 # Torne, what's the problem with modern MLC NAND? 21.16.44 # too many bad blocks? 21.17.20 # MLC NAND has additional write restrictions and usually uses the entire OOB space for a very strong ECC 21.17.27 # leaving no OOB space for any wear levelling or mapping data 21.17.39 # MLC generally requires that the pages of each erase block be written in order 21.17.59 # i.e. you can't erase 0-3 and then write to page 2 then 1 21.18.47 # yes, the problem main understanding the TCC FTL was understanding how it "collects" out-of-order writes 21.18.52 # *main problem 21.18.54 # Torne, interesting 21.19.38 # bertrik: this is one of the areas where i'd love to help but would rather not to avoid legal issues :) 21.20.31 # argh. my bzr-aware version.sh always says the tree is modified, but if i paste the same command into an interactive shell it works :) 21.21.18 # I don't know exactly what kind of NAND is used in rockbox targets 21.21.35 # bertrik: pretty much all modern stuff is MLC 21.21.51 Join paulk_ [0] (n=paulk@lib33-1-82-233-88-171.fbx.proxad.net) 21.21.53 # aha, i'm an idiot 21.22.00 # of course my tree is modified, i've modified tools/version.sh 21.22.04 # :) 21.22.12 # though I think the DAX / m200v3 etc use an older SLC chip 21.22.18 # Hello ! Do you know where I can found a free pacman room for Rockbox ? 21.22.24 # hm, I see most meizus uses MLC indeed 21.22.42 # If you have an FTL that works on MLC NAND it should also work on SLC NAND. 21.22.57 # but that's only useful if you are going to repplace the OF entirely :) 21.23.09 # paulk_: due to copyright bits, you are left on your own with that task...use google 21.23.23 # ok... 21.23.26 # 1) get a pacman machine 21.23.26 # :) 21.23.42 # Torne: a free one! 21.24.03 # I don't know if free pacman rooms are existing... 21.24.03 # if you have a pacman machine, then a pacman rom is free :) 21.24.16 # I know 21.24.26 # Torne, yeah it's a serious dilemma whether to try to be compatible with the OF or completely abandon it 21.24.44 # well, thank-you ! 21.24.45 # bertrik: if you were just going to abandon it then just nick ubi and ubifs from linux. :) 21.24.54 # * shotofadds does not want to abandon the D2 OF. it's too useful for things like DAB (spit!) 21.25.10 Quit paulk_ (Client Quit) 21.25.40 # shotofadds: Then implement DAB instead ;) 21.25.59 # linuxstb: hmm. DAB is rubbish anyway ;) 21.26.14 # shotofadds: Then you can safely abandon the D2 OF ;) 21.26.20 # problem solved! 21.26.48 # * shotofadds thinks TCC FTL is probably easier than DAB... 21.26.54 # implementing DAB sounds easier than FTL 21.27.07 # * shotofadds thinks we have a volunteer ;-) 21.27.13 # DAB is pretty well documented AFAIK. 21.27.29 # and the DAB chip in the D2 too....? 21.28.01 # I just happened to have borrowed a DAB capable ATMT from AlexP 21.28.02 # I mean you "just" need to tune it and get the transport stream packets... After that, you follow the DAB specs. 21.28.20 # bertrik: What a coincidence :) 21.28.37 # well, I wish you the best of luck! 21.28.55 # linuxstb, do you have a link to specs or datasheets? 21.29.01 Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 21.29.03 # actually, working out this FTL should be a whole lot easier now I've got a writable filesystem for debug logs..... 21.29.03 # bertrik: For DAB? 21.29.23 # linuxstb, yes 21.29.28 # New commit by 03zagor (r21725): Fixed build time bug and build list zombie bug. 21.29.31 Quit captainkwel ("Page closed") 21.30.07 # bertrik: I guess this is a place to start - http://www.etsi.org/WebSite/Technologies/DAB.aspx 21.33.50 # shotofadds: UBI sounds somewhat interesting as a starting point 21.35.53 Quit Hillshum (Read error: 110 (Connection timed out)) 21.37.13 Quit J-23 ("wszed³em") 21.37.21 # amiconn, indeed, reading about it now 21.38.49 # New commit by 03mcuelenaere (r21726): utils/analysis/find_addr.pl: fix detection of codec start address 21.39.36 # I like the idea of an open-source FTL implementation that can be improved over time rather than try to reverse engineer something vendor-specific and never really knowing if you did everything just right 21.40.11 Nick AlexP is now known as BigBambi (n=alex@rockbox/staff/AlexP) 21.40.21 Nick BigBambi is now known as AlexP (n=alex@rockbox/staff/AlexP) 21.40.27 # I like that too, but that requires dropping OF support, which some people don't want to even think about 21.40.44 # don't you need to 'convert' the vendor-specific bad-block format to the open source one at the first run? 21.41.21 Join J-23_ [0] (n=zelazko@unix.net.pl) 21.42.05 Nick J-23_ is now known as J-23 (n=zelazko@unix.net.pl) 21.42.06 Quit webguest81 ("CGI:IRC") 21.43.05 # cant we say if you want the OF you dont get write support in rockbox? 21.43.10 # give users the option? 21.44.40 # well, right now there is no open source FTL, and we don't do MTP (yet) so we can't use special flash filesystems, so there's not much option to give... 21.45.23 # mcuelenaere: There could be a mix. Vendor-specific header format but open source algorithm 21.47.20 Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz) 21.48.23 # gevaerts: have a play with fs#10415. see if it breaks anything ;-) 21.48.24 Join Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) 21.48.29 # * amiconn sees build client activity and fires up the other vm 21.51.48 # UBI is not able to hist FAT 21.51.59 # UBI is not an FTL in the traditional sense 21.52.21 # also, just for reference, it's incredibly difficult to write an FTL that doesn't infringe on a gazillion patents. Best not to look. :) 21.52.52 # Torne, can you explain why it can't host FAT? 21.53.02 # because it doesn't implement a block device interface 21.53.55 # You can implement a simple block device FTL on *top* of UBI though 21.54.04 # which takes care of many of the details for you and makes the FTL much simpler. 21.54.09 # but nobody has actually done so yet afaik 21.54.45 # UBI takes care of partitioning, wear levelling, and bad block relocatio for you 21.55.01 # but it still leaves you to deal with erase block restrictions and write block restrictions. 21.55.27 # meh, Ubuntuxer makes me commit my half baked jackpot.tex and related patch just to correct the wrong edit to manual/plugins/main.tex if that part should only appear in manuals for targets with colour screens 21.55.57 # UBIFS is the part which deals with how to thread a filesystem through restricted-write pages 21.57.16 Quit BryanJacobs ("Java user signed off") 21.59.02 Quit LambdaCalculus37 () 22.01.38 # Torne, so the FTL on top of UBI would have to take care of mapping (for example) 512-byte sectors into larger erase blocks? 22.01.53 # and not worry so much about wear leveling? 22.02.50 # it would have to think abotu subpage/page/block size, yes, and any ordering retriction within a block (pages in order for MLC) 22.02.53 # but that's it 22.03.21 # it can basically assume that all the UBI-exposed logical erase blocks are actually 100% reliable and never fail :) 22.03.38 # How can I remove pdbox from applications? I would like it to be associated with .pd files and not to appear anywhere else. 22.04.00 # wincent: just move it to rocks/viewers and update viewers.config to point there 22.04.09 # the plugin menus are just the file hierarchy under 'rocks' 22.05.11 # also modify apps/plugins/CATEGORIES 22.05.24 Quit Xerion (Success) 22.05.24 Nick Xerion_ is now known as Xerion (i=xerion@82-170-197-160.ip.telfort.nl) 22.05.47 # wincent: edit CATEGORIES and viewers.config 22.05.49 # sounds like a nice GSOC project to implement something with UBI :P 22.06.06 # JdGordon|: Did so, but the point with file hierarchy was the one I missed. 22.06.13 # Torne: Thanks! 22.06.29 # Torne: That's why I said UBI is interesting as a starting point 22.06.31 # wincent: if you're building then changing CATEGORIES is enough, that's what determines where the build puts everything 22.06.44 # you only need to actually move the file around if you're working with bianries ;) 22.07.02 # amiconn: there are probably other people at least *considering* doing a regular block device ftl for ubi 22.07.29 # I was thinking on the line of taking ubi code to implement an entire ftl 22.07.32 # Torne: Also, one needs to remove the old .rock if a new one was installed with make install. 22.07.53 # wincent: well yes, new builds aren't going to remove files from old builds 22.07.56 # We can't use ubi as-is anyway, as it's made for linux, and rockbox is quite different 22.08.10 # finally, a proper post-commit triggered build round 22.08.18 # bertrik: depends how google feel about patents there thoguh L:) 22.08.47 # amiconn: yah, but it would be better to have someone from linux mtd implement the ftl and then we rip it off, tbh :) 22.09.00 # well, potentially better 22.09.09 # as they are more likely to know the optimal way to do it :) 22.09.42 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 22.10.24 # well, the linux mtd people probably also have a "Mr. Someone" to do stuff like that 22.10.33 # this is also true. 22.11.01 # i am completely serious when i say that basically anything we or they come up with probably infringes a bunch of patents though 22.11.17 # the storage companies have *tons* of patents in this area :) 22.12.13 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 22.12.16 # * gevaerts now also runs rockbox from SD on a D2 :) 22.12.30 # so you're saying that UBI may already infringe? 22.12.31 # question : I've made a change in a file that would require changing indentation of code already in svn (apps/codecs/cook.c), should the changes be committed on two steps - one for the change in functionality and the other for 'cosmetics', or is it ok to commit it all in one step ? 22.12.32 # New commit by 03zagor (r21727): Clients build stats page. 22.12.36 # * shotofadds is glad to see gevaerts heeded the warnings ;) 22.12.46 # bertrik: it's very likely 22.12.55 # bertrik: anyone involved in developing it will have Carefully Never Looked 22.13.04 # since many countries penalise *knowing* infringement more 22.13.12 # Of course, it also depends where you are in the world 22.13.17 # oh of course. 22.13.42 Quit martian67_ (Read error: 60 (Operation timed out)) 22.13.45 # Here's the diff to clarify what I'm talking about : http://www.pastie.org/539138 22.13.52 # doesnt ignorance mean nothing with patents anyway? 22.14.14 # JdGordon|: ignorance doesn't mean you are innocent, but in some places knowing infringement is automatic triple damages or similar 22.14.26 # gevaerts: pictureflow is nifty on the touchscreen, don't you think? 22.15.02 # we're already infringing on hundreds if not thousands of patents in the codecs, I'm not sure a few more matter 22.15.18 # yah. i'm not saying it's any more of a problem than code we already have 22.15.21 # shotofadds: I'll have to try that 22.15.26 # but... doesnt not searching mean that you assume there is one already anyway? so your up shit creek anyway? :) 22.15.32 # hmm .. the diff went a little bad in shape when copying from the terminal. 22.15.51 # or.. being able t do it without searching means that it was obvious so the patent shuold be invalid :) 22.15.55 # JdGordon|: maybe you were just too busy L) 22.18.50 # mt: Do you mean that you are adding an extra outer-loop, so all the code inside the loop is indented, but without changing? 22.18.51 # Here's a nicer diff : http://www.pastie.org/539150 22.19.18 # linuxstb: Actually, I'm removing an outer-loop. 22.19.29 # mt: Yes, I just figured that out ;) 22.19.33 # :) 22.19.45 # tiny cosmetic question: is there any reason why the icon for the System menu shouldn't be the same as the system settings menu? currently the system menu uses Icon_Questionmark which is a lightbulb in cabbie and a question mark in lots of other themes, whicih makes no sense. the system menu icon is usually a cog, which seems better :) 22.19.59 # (er, the system *settings* menu icon is usually a cog) 22.20.23 # mt: I don't think it's worth committing separately 22.20.29 # i posted a oneliner patch for this on FS#9727 but amazingly nobody has cared to comment :) 22.22.16 # Torne: that is entirely arbitrary... 22.22.24 # I saw your patch and couldnt be bothered chaning it :p 22.22.40 # it is arbitrary, yah, but it looks weird on most themes other than cabbie 22.22.50 # which tend to implement Icon_Questionmark as a question mark :) 22.22.58 # silly them! 22.23.02 # what does cabbie show? 22.23.02 # which means my main menu has a big question mark on it 22.23.05 # Torne: That sounds more like a bug in cabbie... 22.23.05 # a lightbulb 22.23.27 # New commit by 03mt (r21728): Add the ability to seek to the start of the track. 22.23.28 # questonmark != lightbulb... 22.23.38 # Or am I missing something? ;) 22.23.42 # but srsly, i can't see why "System" and "System Settings" should have totally different icons 22.23.59 # my clip shows a question mark, my e200 shows a light bulb 22.24.02 # linuxstb: you migth well consider it a bug in cabbie *as well* 22.24.13 # Torne: Yes 22.24.38 # mcuelenaere: in helloworld.lua, `if not file` looks more luaistic than `if(file == nil)` (even if I'm no expert) and it seems that file:write(str) doesn't return anything so can't be relied on to check if write was done correctly. 22.24.55 # but i don't use cabbie, so hey. it just looks weird on every other theme i've tried :) 22.25.20 # so the actual fix here is to implement customizable icon placement! 22.25.30 # haha 22.26.22 # serisouly... it could be easily done 22.26.35 # every menu has a uniuqe identifier of sorts... 22.26.51 # Torne: Have you noticed where else Icon_Questionmark is used? 22.26.59 # linuxstb: very very few places 22.27.02 # the "rate song" menu 22.27.02 # * linuxstb hands himself grep 22.27.27 # New commit by 03pixelma (r21729): Jackpot is now available on all targets, so enable it for all manuals as well. The button table needs to be filled out still though. Also move the opt ... 22.27.37 # the title for option screens 22.28.04 # and it's used if something tries to ask for an icon that's out of range, also 22.29.40 # JdGordon|: i'm sre it could, but i've used a number of themes and the system menu is the only one that was consistently "out of place" to my eye :) 22.30.41 # so i'd judge our selection of builtin icon constants is not too bad and themers seem to manage ok :) 22.31.11 # petur,domonoky: I just updated the wiki page and the patch for pdbox: http://www.rockbox.org/tracker/task/10416 22.31.24 # Feel free to review. 22.31.27 # wincent: already saw it ;) 22.31.35 # nice work 22.31.37 # mcuelenaere: in fact file:write(str) returns a boolean, that you tried to compare to the number 1 (maybe you thought C code) 22.31.42 Quit efyx_ (Remote closed the connection) 22.39.11 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 22.42.50 # from its description, it doesn't sound like the new plugin Clix would need to be colour only (thinking about symbols for greyscale/mono), but it doesn't look like it's using the external bitmap system so every change there is a bit more complex 22.43.54 # Grahack: corrected 22.44.40 # Grahack: what's your real name? (so I can mention it in the commit message) 22.45.49 # pixelma: Clix? /me looks... 22.46.26 # copyrighted name issue? 22.46.43 # Grahack: I suppose 'if(rb.lcd_rgbpack ~= nil) then' could be simplified to 'if rb.lcd_rgbpack then' too? 22.48.17 # pixelma: I was just wondering where it came from... Was it on flyspray? (the commit message doesn't refer to it). 22.50.24 # linuxstb, yes, FS#8925 22.52.09 Join luke_dozen [0] (n=luke_doz@p54AB62E1.dip.t-dialin.net) 22.52.24 # linuxstb: I thought it was but can't seem to find it now 22.52.52 # * pixelma should also follow the channel 22.54.37 *** Saving seen data "./dancer.seen" 22.55.55 # New commit by 03pixelma (r21730): Use the correct (feature) option to only include the new clix.tex in manuals of targets with colour screens. 22.56.17 # mcuelenaere: Christophe Gragnic 22.56.34 Quit Hillshum (Read error: 104 (Connection reset by peer)) 22.58.06 # mcuelenaere: `false~=nil` is true so it depends if false is accepted 23.01.06 Join blackdeagle [0] (n=blackdea@dslb-092-074-204-070.pools.arcor-ip.net) 23.01.14 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 23.02.16 # good night/day everyone 23.02.20 Quit Grahack ("Leaving.") 23.02.35 Quit martian67 (SendQ exceeded) 23.03.58 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 23.05.58 # New commit by 03mcuelenaere (r21731): Helloworld.lua: fix file_put_contents depending on a wrong return value of io.write + use a cleaner version of if(file == nil) (thanks to Christophe ... 23.06.12 Join balug_ [0] (n=dvg@HSI-KBW-078-042-132-156.hsi3.kabel-badenwuerttemberg.de) 23.06.44 Quit Strife89 ("Dinner is almost ready.") 23.07.03 # AlexP: (or others) what would you think about the following indentation style for button tables? http://rockbox.pastebin.ca/1488842 (as an example) 23.07.43 Quit bmbl ("Bye!") 23.08.16 # the goban button table almost made me go crazy, which is why I thought about one - documented - style and then changing them bit by bit 23.09.08 # pixelma: I'd add another line of whitespace between each table line like: http://rockbox.pastebin.ca/1488847 23.09.15 # but yes, I agree 23.09.27 # just need to settle on one style (also one for the "directional key" mess 23.09.32 # Current button tables are often a nightmare 23.09.44 # or settle for? 23.10.25 # Depends on context, here I would say settle on :) 23.11.08 # AlexP: yes, could live with that too, most important to me was to easily see the start of new columns and rows 23.11.52 # Yes, I agree 23.14.25 # there might be corner cases which don't fit into that scheme (which I don't know about yet, guess you'll only see when actuall trying to fit them 23.15.23 Quit n1s ("Lämnar") 23.15.41 # Yeah, but as a general guide it can only be a good thing 23.16.07 # the second column could be a problem with the remotes... maybe then an \opt{REMOTEKEYMAP} around them which includes the & and then opting the exact pad seperately? 23.16.26 # nested, I mean 23.16.39 Quit blackdeagle (Remote closed the connection) 23.17.27 # pixelma: Yes, that could be good - then tables automatically work with remotes, and people can add in the buttons later 23.17.35 Quit petur ("Zzzzzz") 23.18.03 # Someone adding a remote wouldn't have to add \opt{whatever}{&} to every single sodding table :) 23.19.09 # hrrmm.. should have done that then. Although - since it's only one pad currently, that could be a search and replace thing 23.20.13 # but as it looks like we have to go through all tables anyways, it's not a big thing 23.20.22 # * domonoky hears a sinus with pdbox ! :-) 23.20.56 # pixelma: yep 23.21.13 # Hello all, I have a problem: PDBox uses original code from Pure Data which causes warnings about strict aliasing. Does it have to be corrected or can it be left as it is? 23.21.36 # AlexP: any preference for the "directional keys"? Some tables list left/right/up/down on their own line, some combine left/right, some put them all together, some just mention "directional keys"... 23.22.11 # I think that depends on bit on the player unfortunately 23.22.40 # Those with a clear up/down/left/right (e.g. H100, beast, ...) could just say directional keys 23.23.01 # Others such as c200 where they are also used for other things are a little more tricky 23.23.50 # I think directional keys when it is clear, and specify the keys when it is less so 23.24.10 # *I* wouldn't think the c200 is special there in plugins (but maybe I'm already a bit blind for things newbies can struggle with), Ipods on the other hand... 23.24.21 # yeah 23.24.52 # But for those where it is clear I think directional keys is my preference 23.26.24 # hard to make a guideline out of this then. I just think that the current situation could be better there and I mostly dislike those longish lists in some tables. I'm trying to put the indentation part on the LatexGuideline wiki page tomorrow 23.26.40 # wincent: you could probably disable that warning in the pd make file, but fixing it would be the best option if its possible 23.27.25 # and give it a little time for people who have objections to speak up, if there aren't any - start changing the tables 23.27.32 # yep 23.27.46 # I won't be until next week, out tomorrow and away this weekend 23.28.23 # saratogalab: For example, in d_soundfile.c the strange casting construction that causes a warning converts a float to long, to write it out to a sound file byte-wise later. 23.29.26 # AlexP: alright, I already know your opinion (and will take your suggestion) :) 23.29.47 # * amiconn wonders whether he should fix the bogomips offset, and whether such a fix would warrant a client version bump 23.29.48 # saratogalab: So fixing it would be interesting, involving some float/int32_t unions. 23.31.05 Join stephen_ [0] (n=stephen@86-45-97-240-dynamic.b-ras2.srl.dublin.eircom.net) 23.32.04 # Zagor? ^^ 23.32.23 # amiconn: the bogomips offset? You mean the +1? 23.32.27 # offset? 23.32.29 # What would the point be? 23.32.37 # yes 23.32.40 # It's not like bogomips means anything useful anyway 23.32.42 # Just cosmetic... 23.32.51 # wincent: Why would you need to convert to an int to write byte-wise? Couldn't you just treat it as an array of chars? And what are floats doing in Rockbox? ;) 23.33.48 # the bogomips value is very unimportant. it is just a coarse sorting tool for the server. 23.34.26 # linuxstb: It's not me :-) As I said, it is the original code. 23.35.18 # linuxstb: And about floats... Well, only sound-data is fixed-point in PDBox; control-data is not. 23.36.41 # wincent: is that function used for reading in fp data? 23.37.05 Quit stephen_ ("Leaving") 23.37.14 # saratogalab: Yes, and for writing it out too. 23.37.43 # do you anticipate needing to read in fp data ? 23.38.02 # requiring integer input would seem to be more efficient, unelss this is for compatibility 23.38.05 # "fp" = floating point or fixed point? 23.38.34 # I love you guys 23.39.04 # I haven't had a mp3 player yet to play with rockbox on, m200 sansa bit the dust and the display was broken and it wasn't supported yet anyways 23.39.15 # but I do plan to get one since I don't like using my palm t5 to do music 23.39.34 # but it looks like the $8 mp3 player I bought like 3-4 yrs ago will have support in the future also :P 23.39.37 # samsung soc 23.39.51 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.41.08 # flyback: i don't think theres any ports to really old mp3 players in progress using a samsung SOC 23.41.34 # well I saw some info on the page and there is support for some of the newer samsung soc's 23.41.42 # it's not a big deal it's half dead anyways, missing case and lcd 23.41.48 # just kinda neat that people actually try 23.41.57 # I will just end up buying a cheap mp3 or refurb mp3 that is supported 23.42.08 # flyback: ports are to MP3 players, not SOCs 23.42.17 # uh I know that 23.42.22 # but you have to support the SOC also :P 23.42.25 # linuxstb: yes its float if I am grepping correctly 23.42.44 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 23.45.46 # saratogalab: It's really for compatibility's sake only. 23.46.34 Join Stephen_ [0] (n=S@86-45-97-240-dynamic.b-ras2.srl.dublin.eircom.net) 23.47.04 # linuxstb: If you'll look into the floating-point hell called pdbox-func.c , you won't have any such question anymore :-> 23.47.28 Join calaco [0] (n=46462073@gateway/web/cgi-irc/labb.contactor.se/x-ce548f28ede97ff0) 23.47.34 # wincent: with all that floating point how is performance? 23.48.07 # SanDisk Sansa e280 rockboxable. yes/no?? 23.48.19 # saratoga, I understand completely that soc support !=rockbox/device support 23.48.21 # calaco: check front page 23.48.22 # gevaerts, has it ever been tried to replace the RAR in the meizu upgrade image with another RAR (containing rockbox code for example)? 23.48.26 # all I saying is you have to start with soc support 23.48.27 # calaco: v1, yes 23.48.35 # bertrik: pronably not 23.48.35 # if you don't have that there's 0 chance they will move to device support 23.48.38 # calaco: yes, but only v1 are "stable" v2 is in development. 23.48.41 # saratogalab: Well, a lone sine oscillator is working. 23.48.55 # k thx 23.49.01 # wincent: My question was simply what did saratoga mean with the abbreviation "fp" - we're talking about a program with both fixed and floating point, and I would use that abbreviation for either.... 23.49.03 # wincent: but if this is to be useful it has to run much more then that in real time right? 23.49.26 # hmm... it looks like RbUtil needs a connected player to change unrelated settings? At least now when I tried changing its language to english I got a "Mount point not found" when pressing OK until I connected one of my players 23.49.38 Quit mt (Read error: 113 (No route to host)) 23.49.40 # saratogalab: If not, I'll have to do a CPU boost. 23.49.40 Quit calaco (Client Quit) 23.51.07 # linuxstb: It's all right, it's just about the fact that about 90% of pdbox-func.c is a reimplementation of the needed floating point functions. I plan to simplify most of them, though. 23.51.10 # pixelma: rbutil checks the important settings like player and mountpoint on closing of the config window.. what do you want todo with rbutil without a player connected ? 23.51.34 # domonoky: Read a manual? 23.51.44 # look how the tabs, buttons etc. are called to give support 23.52.20 Quit flydutch ("/* empty */") 23.52.31 # linuxstb: you cant read it in rbutil, it only provides the link and a download button... :-) 23.52.35 # and for that I wanted to know how they are called in English and had to switch languages ;) 23.52.54 # domonoky: download a manual? 23.52.56 # domonoky: Then "Download a manual?" 23.53.04 # you can also point it to some random directory, it wont care :-) 23.53.21 # it just has to exist and be writeable. 23.53.26 # domonoky: "checks the important settings"? ;) 23.53.29 # saratogalab: Of course, the (fixed-point) DSP itself is much less complicated than control processing, which resorts to floating-point. 23.53.37 # So if the check doesn't actually matter, why force chosing a meaningless directory? 23.53.46 # I, as an illiterate for those things would never have though of that 23.53.54 # me neither 23.53.59 # to force the stupid people todo it :-) 23.54.11 # but thats a thing for improvement... 23.54.28 # Trouble is, if people don't guess they need to do that (and I wouldn't have), then you can't force them too :) 23.54.33 # Maybe split "settings" and "player configuration" ? 23.54.53 # could imagine that very well 23.55.02 Nick J-23 is now known as J-23|away (n=zelazko@unix.net.pl) 23.55.08 # AlexP: we want them to connect the dap. nearly all functions need it. 23.55.17 # but not all 23.55.48 # This is maybe a thing more for us - I too have been annoyed by this when trying to look something up for support, but I guess this isn't a standard use case 23.56.57 # "we" also know how to trick rbutil :-) 23.57.12 # only now 23.57.13 # apparently not though, as neither pixelma nor I did :) 23.57.14 Quit balug_ ("Ex-Chat") 23.57.36 # but autodetection and presentation of current device is a long standing issue i want to improve.. 23.58.07 # also "mount point not found" (or the like) doesn't tell me much 23.58.31 # pixelma: feel free to improve the user texts in rbutil :-)