--- Log for 28.08.108 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 7 days and 4 hours ago 00.00.24 # if youre using an index other than 3 or 4, the yes it will always be 65535, so far as I can tell 00.00.27 # hmm let me see 00.00.54 # I still wish someone (Slasheri?) would pick up FS#7984 00.01.18 # 3 and 4 shoudl map uniquely onto indicies in the main index 00.01.53 # reacocard: wait, my parser is acting weird atm 00.02.00 # kugel: kk 00.02.24 # * reacocard is writing up the fat32 mtime layout for the wiki 00.02.33 # * amiconn wonders whether the one db bug he reported ages ago will be fixed before 3.0 00.02.34 Join CyBergRind|w [0] (n=cbr@212.98.160.130) 00.03.00 # reacocard: The fat32 specs are on the datasheet page. No need to repeat information... 00.03.12 # amiconn: ah thanks, Ill just link to that then 00.03.45 # * reacocard hasnt explored all of the wiki yet :) 00.04.01 # reacocard: my parser fails to read the bytes on that 2 files 00.04.16 # kugel: wierd, mine handles them fine 00.04.26 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 00.05.16 # bye bye 00.05.20 Quit Casainho ("ChatZilla 0.9.83 [Firefox 3.0.1/2008072820]") 00.05.41 # * amiconn will fiddle a bit with mtime code after the freeze ends 00.05.50 # heh 00.06.06 # I guess I better upload the mtime-enabled version of my parser too 00.06.32 # Targets without rtc need to fake time stamps. Currently such a build chooses its own build date as starting point for new files 00.06.40 # ew 00.06.54 # thats going to be tricky to handle 00.06.56 Join Zarggg [0] (n=z@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 00.07.24 # Existing files will increment the mtime by a fixed amount (1h 15min) when writing 00.07.26 # well, maybe not, since I can just use the real timestamp right? 00.07.30 # ugh 00.07.55 # * reacocard will think about that later 00.08.15 # reacocard: is there something special to the 2 files? it's really weird. I can extract the filename just fine. 00.08.22 Join oofus [0] (n=chris@oofus.demon.co.uk) 00.08.29 # kugel: I use the exact same parser for each 00.08.32 # But this isn't ideal if there's an oold file on the disk. Even if it's incremented in 1h 15min steps, the file date will stay behind the build date for quite some time 00.08.50 # reacocard: so i do 00.09.17 # kugel: perhaps you should look at my code and see what you're doing differently? 00.09.25 # reacocard: I don't think you need to worry about this. The db holds audio track file data. Those files are usually copied from a pc, and hence have a real time stamp (if the pc's rtc is correct) 00.09.45 # reacocard: a) i can't read python so well b) my parser works different to yours, from what I've read 00.09.51 # What I'm talking about are files written/updated *by rockbox itself* 00.10.10 # amiconn: ok 00.10.11 # But I parse every database_[0-9]+.tcd exactly the same 00.10.33 # kugel: well, im no great shakes at ruby but Ill give reading yours a stab 00.10.42 # where can I find it? 00.10.48 # So I think it would be an improvement if rockbox checks the timestamp of a to-be-updated file, and if it's before its own build date, advances it to that instead of doing the small incements 00.11.14 Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 00.11.29 # http://pastebin.ca/1186826 00.11.58 # could we track "time spent in Rockbox" (similar to "time since last charge") and just make the timestamp "build date + time in rockbox")? 00.12.13 # line 55 and 56 are causing problems, but only on _3 and _4 00.12.51 # Llorean: How would that be better? You cannot track the time the device was swicthed off 00.12.58 # its impressive how much smaller 7zip builds are then zips 00.13.20 # reacocard: you'll need ruby 1.9 in case you want to run it 00.13.24 # amiconn: it would at least keep all rockbox generated timestamps in the right order 00.13.29 # kk 00.15.01 # gevaerts: I'd prefer the time stamps to stay relatively close to real-world time rather than having them 100% in order 00.15.15 # You cannot have both without an rtc 00.16.17 # You could reset the base every time you detect a new build. That would keep it closer to real-world, but you will get out of order timestamps again 00.16.26 # * gevaerts doesn't care much 00.16.46 # If you care about exact times, use a player with an RTC I guess 00.17.21 # Well, what we could actually do is use both a time stamp "counter" and the build time to adjust the step size 00.17.25 # kugel: so what's the invocation to run it? 00.17.47 Quit DerDome ("Leaving.") 00.18.05 # If it has to go back when installing a new build, the step size was too large -> decrease 00.18.11 # reacocard: have the database files in a "db_files/" subdir, then just do"ruby rb_db.rb" 00.18.27 # Next time there's a better chance that it doesn't have to go back 00.18.32 # kugel: kk 00.18.42 # Except if you now and then install an older build 00.18.50 Quit Zom ("leaving") 00.18.51 # Likewise, if it has to advance a lot with a new build, step size was too small 00.18.54 # of course you can run it in the same dir, just alter the PathToDBFiles variable 00.19.01 # ah thanks 00.19.26 # Or learn a lesson from DOS. Ask the current time at boot :) 00.19.43 # hahaha. That would be a major annoyance... 00.19.52 Quit [CBR]Unspoken|w (Connection timed out) 00.20.11 # You could do that by adding the set time/date screen to the possible startup screens 00.20.32 # The time/date screen doesn't exist on non-rtc targets 00.20.35 # Not such an insane idea 00.20.55 # And I'd rather not introduce it 00.20.56 # I'm sure some lastfm users and tapers might like it 00.21.01 # * gevaerts still thinks that there are enough players with an RTC to keep this simple and tell people who complain to get another player 00.21.19 # It would require enabling a lot of other code that's currently disabled for non-rtc 00.21.29 # gevaerts: any with digital input/output? 00.21.38 # rasher: yes 00.21.42 # agrees with gevaerts 00.21.49 # amiconn: Optical, then! 00.21.59 # (which is in fact what I meant) 00.22.00 # Why does it need to be optical? 00.22.14 # Converting optical <-> coax is rather simple 00.22.17 # kugel: so, funny story. your parser read those entries perfectly on my system 00.22.22 # rasher: mod it? 00.22.32 # I've made the COP thread actually call thread_exit(), and verified that the main codec thread passes the call to ci->thread_wait(), but it still waits forever at 0:00 in the next track 00.22.34 # amiconn: And there's how many that aren't hwcodec though? 00.22.37 # amiconn: Just because I'm aiming at telling that "h1x0 users might want it" 00.22.41 # reacocard: Have you changed anything? I gave you the version which fails 00.22.55 # kugel: nope, not a single character 00.23.05 # reacocard: your system is? 00.23.18 # Llorean: None afaik, but that wasn't included in the original question 00.23.33 # ubuntu 8.04, database is from a sansa e200 sim with 5 mp3s 00.23.44 # * kugel slaps himself 00.23.54 # ? 00.23.55 # I got it, nevermind ;) 00.23.58 # lol 00.24.18 # I forgot to enter binary mode (which is needed on windows), for linux there's no binary mode 00.24.21 Join RoCkEr [0] (n=cb0a7953@gateway/web/cgi-irc/labb.contactor.se/x-da110f649d339009) 00.24.27 # ah yeah that would do it 00.24.41 # * reacocard double-checks to make sure he's using binary mode 00.24.49 # "* amiconn wonders whether the one db bug he reported ages ago will be fixed before 3.0" => filing a bug report on flyspray will probably improve the odds 00.24.50 # saratoga: I'm quite sure that you don't need thread_exit() 00.25.05 # yeah mine already uses it anyways 00.25.05 # reacocard: On linux, there's no difference between binary mode and non-binary mode 00.25.11 # actually, it can play ogg after mp3, so its likely a problem with me not reiniting the cop thread in the next track i think 00.25.18 # kugel: im aware but I like my code cross-platform 00.25.20 # is rockbox available for classic yet? 00.25.25 # on windows, you need to open the files in binary mode 00.25.31 # yep 00.25.36 # I don't know if python has such a thing 00.25.38 # RoCkEr: no, and don't hold your breath for it 00.25.39 # in my case "rb+" 00.25.44 # the b is for binary 00.25.50 # yea, same for ruby 00.25.51 # reacocard: rockbox plus? 00.25.58 # k, what about linux? 00.25.59 # r for read, + is some kinda appendy thingy 00.26.12 # reacocard: what about linux? 00.26.14 # RoCkEr: yes please. Eh that's a question? 00.26.20 # reacocard: + is for read+write 00.26.21 # RoCkEr: what has this to do with Rockbox? 00.26.22 Nick oofus is now known as oofus[away] (n=chris@oofus.demon.co.uk) 00.26.25 # I entered it when creating a RockboxDB object, but not when creating a RockboxDBTag one for testing 00.26.32 # rasher: ah, of course 00.26.47 # is ipodlinux available for classic? 00.26.48 # Nico_P: There is one for this bug... fs #9093 00.26.59 # RoCkEr: Go ask them. 00.27.02 # RoCkEr: nope 00.27.14 # * kugel liked rasher's answer more 00.27.15 # that bites 00.27.17 # I hear their site is hard to find ;-) 00.27.37 # yep 00.27.37 Quit bertrik ("Leaving") 00.28.10 # Bagder: thanks anyway 00.28.16 # I hear they have an irc channel :) 00.28.29 # what is it? 00.28.30 # reacocard: Good to know I can ignore the 2bytes 00.28.37 # at least for reading 00.28.56 # kugel: heh, just be careful when you ignore stuff. it tends to bite you if youre not careful >.< 00.29.29 # reacocard: I mean, I'm reading them, but I don't do anything with the master index 00.29.38 # reacocard: Yeah it does. You miss one bit of code it screws other things over 00.29.47 Quit bluebrother (Nick collision from services.) 00.29.52 Join bluebrother [0] (n=dom@rockbox/staff/bluebrother) 00.30.06 # yeah, I dont do anything cross-db yet. thats the next step now ^___^ 00.30.11 # I'll surely take care if my program happens to write the database 00.31.03 # so I can play an mp3, then an ogg and finally another mp3, but if I try to play 2 mp3s in a row the codec thread deadlocks 00.31.09 # reacocard: New entries can just be appended to the tcd files, correct? 00.31.18 # kugel: I believe so yes 00.31.35 # does anything special happen when a new codec is loaded verses when the same codec is used twice in a row? 00.31.51 # * reacocard will be more recreating the DB than just updating it, but will preserve all the statistics 00.31.53 # reacocard: can you tell how the database version byte is needed? 00.32.09 # saratoga: When the same codec is used twice, it's not reloaded 00.32.10 # kugel: when the db format changes I think it increments 00.32.25 # so its just a way to check for compat 00.32.37 Quit waldo (Remote closed the connection) 00.32.39 # does reloading do additional initialization? 00.33.25 # Seems to have changed a lot then 00.33.33 # yeah that was my thought 00.33.43 # * kugel doubts that 00.33.59 # exit 00.34.02 # but it hasnt incremented for the few days ive been following svn so I guess it only changes when theres an update 00.34.07 Quit RoCkEr ("CGI:IRC") 00.34.30 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 00.35.10 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 00.35.55 # saratoga: doesn't seem like it 00.36.09 Quit ender` (" But there, everything has its drawbacks, as the man said when his mother-in-law died, and they came down upon him for the f") 00.36.11 Join gaurdro [0] (n=Menschen@unaffiliated/gaurdro) 00.36.30 # oh wow! 00.36.32 # well, init_mad is called again, but not codec_init 00.36.43 # i put the thread init on the wrong side of next_track 00.37.00 Quit bughunter2 (Read error: 104 (Connection reset by peer)) 00.38.50 # reacocard: /* Tag Cache Header version 'TCHxx'. Increment when changing internal structures. */ 00.38.52 # #define TAGCACHE_MAGIC 0x5443480c 00.39.05 # alright works nicely now 00.39.06 # yep, thats what I thought 00.39.18 # so someone mustve jsut thought it would be fun to use a really high value 00.39.43 # reacocard: Well, then we're reading it wrong. I think it should read something with TCH 00.39.59 # hm 00.40.46 # well no, TCH is bigger than the size of that int 00.40.47 # saratoga: nice :) 00.41.06 # TCH is three bytes but its a two-byte value 00.41.31 # 0x5443480c *is* TCHx (with x == 0x0c == 12) 00.41.40 # saratoga: have you seen noticeable improvements from this? 00.42.07 # reacocard: it's 4byte 00.42.20 # Nico_P: I have to turn on the EQ to get it to boost 00.42.24 # so thats nice 00.42.28 # indeed 00.42.31 # agh 00.42.42 # * reacocard should stop relying on his memory when hes distracted 00.43.16 # yeah 0x5443480c & 0x000000ff gives 12 00.43.20 # Nico_P: about 35% boost with all the EQ stuff flipped on 00.43.21 # which is reasonable 00.43.37 # saratoga: What are you testing on? 00.44.06 # Sansa e200 with LAME -V2 mp3s 00.44.14 # saratoga: how much boost does it give with a standard build? 00.44.21 # mcuelenaere: still around? 00.44.25 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 00.44.35 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 00.44.57 # gevaerts: i think around 25-30% 00.45.00 # saratoga: Might be nice to have someone with the 5G test it. IIUC, the UI becomes sluggish during playback when it's not boosted. 00.45.12 # heh still can't run test codec 00.45.35 Join LambdaCalculus37 [0] (n=LambdaCa@c-24-0-218-198.hsd1.nj.comcast.net) 00.47.39 # I suspect a thread sync issue 00.51.21 Quit bluebrother ("leaving") 00.52.14 Join perrikwp [0] (i=d1a8d351@gateway/web/ajax/mibbit.com/x-9ffa0f68d7d56630) 00.53.00 Join EricPierce [0] (n=48c41bfc@gateway/web/cgi-irc/labb.contactor.se/x-84f52e6f507f0389) 00.53.53 Join EspeonEefi [0] (i=espeonee@STRATTON-TWO-O-FOUR.MIT.EDU) 00.55.03 # scorche|sh: yes 00.55.22 # Hi, I'm Eric Pierce. I just registered on the Wiki (ID:EricPierce) and would like to graciously request write access to the twiki. I've created a new theme for the Sansa c200/c250 devices. Here's a screenshot: http://i37.tinypic.com/2yp1287.jpg 00.55.26 # mcuelenaere: so why were you after the current code if it is not going to be used? 00.55.48 # updated FS#9318 00.56.06 # scorche|sh: why is it not going to be used? (I'm talking about the rbutil*.php files) 00.56.09 # should work on PP502X where X> 0 00.56.21 # mcuelenaere: ah... 00.56.29 Quit amiconn (" reboot") 00.56.31 # EricPierce: I'll get on to it 00.57.13 # mcuelenaere: i am in the middle of moving at the moment, but when i get settled down in a couple of day, i will check it in, alright?...or did you need it now? 00.57.38 # no, not necessarily now; it's rather low-priority 00.57.55 # perhaps someone else has the files too? 00.58.50 # linuxstb does, likely...i can give them to you now if you wish...just saying i can check them into SVN in a couple days 00.58.52 # EricPierce: should be done. Now please don't spam :) 00.59.15 # Nice to see more c200 themes by the way 00.59.26 # yeah, my thought exactly when I visited that page. 00.59.29 # thanks a lot! 00.59.45 Quit saratoga ("CGI:IRC") 01.00.05 Join saratoga3 [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-12c24c37f9698172) 01.00.34 Join amiconn [50] (n=jens@rockbox/developer/amiconn) 01.00.43 # scorche|sh: if you can send them now, that would be nice. I'll put them in SVN myself then 01.00.51 Quit LambdaCalculus37 ("Do quit now, there's a demon around the corner!") 01.05.54 Quit faemir ("Leaving") 01.05.56 Quit Nico_P (Remote closed the connection) 01.07.15 Join _emp [0] (n=tweaker@ip68-230-75-227.ph.ph.cox.net) 01.07.53 # gevaerts: Since the mtime delta adjustment would need both old and new build date, it could also detect downgrading 01.08.03 Quit EricPierce ("CGI:IRC") 01.08.20 # I don't think we need such a suophisticated method though 01.09.54 # I agree. You won't get accurate timestamps anyway 01.10.09 Quit XavierGr (Nick collision from services.) 01.10.19 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 01.13.04 Join Sharona [0] (n=IceChat7@86.51.49.221) 01.13.11 Quit EspeonEefi ("さよなら") 01.13.26 Join bughunter2 [0] (n=j@77.164.66.126) 01.14.00 Quit einhirn (Read error: 104 (Connection reset by peer)) 01.15.44 Join EspeonEefi [0] (i=espeonee@STRATTON-TWO-O-FOUR.MIT.EDU) 01.16.45 # <_emp> hello 01.23.02 Quit massiveH (Read error: 110 (Connection timed out)) 01.23.19 *** Saving seen data "./dancer.seen" 01.23.56 Quit Sharona ("REALITY.SYS Corrupted: Re-boot universe? (Y/N/Q)") 01.26.17 Join massiveH [0] (n=massiveH@pool-96-242-223-128.nwrknj.fios.verizon.net) 01.27.59 Quit gaurdro (Read error: 113 (No route to host)) 01.34.01 Quit gevaerts (Nick collision from services.) 01.34.02 Quit jon-kha (kornbluth.freenode.net irc.freenode.net) 01.34.02 NSplit kornbluth.freenode.net irc.freenode.net 01.34.02 Quit Slasheri (kornbluth.freenode.net irc.freenode.net) 01.34.11 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 01.34.19 Quit mcuelenaere ("Zzzz") 01.34.51 # <_hc> anyone here ever tried to get Rockbox on a Sansa Connect? 01.35.21 NHeal kornbluth.freenode.net irc.freenode.net 01.35.21 NJoin jon-kha [0] (i=jon-kha@kahvi.eu.org) 01.35.21 NJoin Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) 01.36.04 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 01.39.09 Quit _emp (Read error: 110 (Connection timed out)) 01.39.29 # _hc: check the wiki, but i don't recall anyone looking into it 01.39.56 # _hc, if anyone is working one the connect, there is a wiki and forum thread 01.40.54 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 01.41.09 # krz_, domonoky: (for the logs) Rockbox built with gcc >= 4.0 uses the "-Wno-pointer-sign" switch to avoid warnings about signedness of pointers. That is probably missing from the wps editor build and thus gcc emits warnigns in rockbox code when building the wps editor but not in regular builds. 01.42.23 Part toffe82 01.43.24 Nick Kopfgeldjaeger is now known as Kopfi|offline (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 01.45.13 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 01.47.22 Join _emp [0] (n=tweaker@ip68-230-75-227.ph.ph.cox.net) 01.47.33 Quit XavierGr () 01.47.42 Quit MethoS (Read error: 110 (Connection timed out)) 01.52.57 Quit massiveH (Read error: 104 (Connection reset by peer)) 01.56.32 Part pixelma 01.58.24 Join tweaker_ [0] (n=tweaker@ip68-230-75-227.ph.ph.cox.net) 01.59.12 # <_hc> advcomp2019: I guess not then, I haven't found much activity... they run Linux natively, too bad they use an encrypted bootloader... 02.05.38 # unless they've posted the source code for what they run, thats not so important 02.06.06 # its mostly about how much info is available about the system and CPU, how similar it is to existing targets, and how much work is required to load code on it 02.08.18 Quit kugel ("ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]") 02.13.56 Quit culture (Read error: 110 (Connection timed out)) 02.14.21 Join mazling [0] (i=largeear@host86-145-122-226.range86-145.btcentralplus.com) 02.14.32 Quit _emp (Read error: 110 (Connection timed out)) 02.21.18 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 02.21.44 Quit Zarggg (Excess Flood) 02.21.55 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 02.21.59 Join xovious [0] (n=47412412@gateway/web/cgi-irc/labb.contactor.se/x-4b11707053d832d3) 02.22.08 # hi anyone here 02.22.12 # llo 02.22.19 # gt 02.22.21 # ji 02.22.22 # i 02.22.22 # i 02.22.29 Quit xovious (Client Quit) 02.22.39 Quit Slasheri (kornbluth.freenode.net irc.freenode.net) 02.22.39 NSplit kornbluth.freenode.net irc.freenode.net 02.22.39 Quit jon-kha (kornbluth.freenode.net irc.freenode.net) 02.22.56 Quit vort3x (kornbluth.freenode.net irc.freenode.net) 02.22.56 Quit sbhsu_ (kornbluth.freenode.net irc.freenode.net) 02.24.09 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 02.25.25 NHeal kornbluth.freenode.net irc.freenode.net 02.25.25 NJoin jon-kha [0] (i=jon-kha@kahvi.eu.org) 02.25.25 NJoin Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) 02.25.45 Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 02.26.12 Join tvelocity [0] (n=tony@gw1.mycosmos.gr) 02.26.14 Quit tvelocity (Client Quit) 02.26.14 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 02.26.14 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 02.27.15 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 02.27.15 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 02.27.20 Nick oofus[away] is now known as oofus (n=chris@oofus.demon.co.uk) 02.27.54 Quit freqmod_qu (SendQ exceeded) 02.29.25 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 02.29.25 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 02.29.25 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 02.29.25 Ctcp Flood: Ignoring PING flood by gevaerts!n=fg@rockbox/developer/gevaerts 02.30.01 Ctcp Ignored 1 CTCP requests in 0 seconds at the last flood 02.30.01 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 02.31.43 Join jac0b [0] (n=jac0b@user-112085h.dsl.mindspring.com) 02.33.22 # GodEater, how is the gigabeat S charging patch working have you tested it? 02.34.58 Quit Lambdumb (Read error: 110 (Connection timed out)) 02.36.40 Quit Slasheri (kornbluth.freenode.net irc.freenode.net) 02.36.40 Quit jon-kha (kornbluth.freenode.net irc.freenode.net) 02.36.41 Nick tweaker_ is now known as _emp (n=tweaker@ip68-230-75-227.ph.ph.cox.net) 02.36.44 # <_hc> saratoga3: I have two, so I get info on the hardware :) 02.36.52 # <_emp> I just submitted my patches; I hope I did it right. 02.39.28 Join massiveH [0] (n=massiveH@pool-72-76-34-19.nwrknj.fios.verizon.net) 02.39.28 Quit oofus (Remote closed the connection) 02.39.29 Quit beta2k_ (Read error: 113 (No route to host)) 02.39.29 # ooh, i missed the beast charging patch. something i can help test, yay 02.40.43 Join massiveH_ [0] (n=massiveH@pool-72-76-34-19.nwrknj.fios.verizon.net) 02.41.44 NJoin jon-kha [0] (i=jon-kha@kahvi.eu.org) 02.41.44 NJoin Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) 02.42.35 # <_hc> saratoga3: the manufacturer released their sources: http://www.anythingbutipod.com/forum/showthread.php?t=13793 02.42.57 Quit massiveH (Nick collision from services.) 02.43.01 Nick massiveH_ is now known as massiveH (n=massiveH@pool-72-76-34-19.nwrknj.fios.verizon.net) 02.47.13 Quit Slasheri (kornbluth.freenode.net irc.freenode.net) 02.47.13 Quit jon-kha (kornbluth.freenode.net irc.freenode.net) 02.53.58 Quit ghen (kornbluth.freenode.net irc.freenode.net) 02.53.58 Quit suom1 (kornbluth.freenode.net irc.freenode.net) 02.55.31 NJoin jon-kha [0] (i=jon-kha@kahvi.eu.org) 02.55.31 NJoin Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) 02.59.05 # _hc: is there any Sansa related code in there? I'm not familar with embedded linux but i mostly see a lot x86 stuff in that source 02.59.43 NJoin ghen [0] (n=geert@lori.ghen.be) 02.59.43 NJoin suom1 [0] (i=markus@viitamaki.net) 02.59.45 # <_hc> that I don't know, legally, there has to be, based on the GPL 03.00.07 # saratoga3, zing made the connect 03.00.12 # <_hc> yup 03.00.30 NJoin vort3x [0] (n=vortex@unaffiliated/dfa001) 03.00.34 # <_hc> also, I just found a good page with info: http://www.rockbox.org/twiki/bin/view/Main/SansaConnect funny because I searched that site before, I found it as a link from a forum 03.00.42 # a lot of companies don't release driver source code though 03.02.07 # <_emp> a lot don't release documentation either; so sad. 03.02.16 # <_hc> very much so 03.02.28 # <_hc> ever tried to talk to people at any of the companies? 03.02.39 # <_hc> didn't Sandisk sponsor some rockbox work? 03.03.04 # ah I see theres a diff for the Connect specific stuff 03.03.12 # that was nice of them 03.03.39 # <_hc> this thing has a voip chip, it has a lot of potential 03.04.24 # _hc: they basically gave the project a couple of e200's and no documentation, Bagder's site has all the details if you are interested. 03.04.40 # <_hc> hmm, not much, but better than nothing... 03.05.03 Quit Slasheri (kornbluth.freenode.net irc.freenode.net) 03.05.03 Quit jon-kha (kornbluth.freenode.net irc.freenode.net) 03.08.33 # <_hc> do you think people from the manfactrers ever hang out in this room? it's strange to me that they would try to prevent people from putting their own firmwares on them, I wonder how hard they persue it 03.09.24 Join Slasheri [0] (i=miipekk@xen.ihme.org) 03.09.24 Join jon-kha [0] (i=jon-kha@kahvi.eu.org) 03.09.25 Quit jon-kha (kornbluth.freenode.net irc.freenode.net) 03.09.25 NSplit kornbluth.freenode.net irc.freenode.net 03.09.25 Quit Slasheri (kornbluth.freenode.net irc.freenode.net) 03.09.45 NHeal kornbluth.freenode.net irc.freenode.net 03.09.45 NJoin Slasheri [0] (i=miipekk@xen.ihme.org) 03.09.45 NJoin jon-kha [0] (i=jon-kha@kahvi.eu.org) 03.10.31 Quit CyBergRind|w (SendQ exceeded) 03.12.21 Join toffe82 [0] (n=chatzill@adsl-71-132-86-163.dsl.sntc01.pacbell.net) 03.12.31 Quit n1s () 03.13.18 Nick Bensawsome is now known as Awsomebot (n=Bensawso@unaffiliated/bensawsome) 03.13.29 # theres some MTP code in there 03.14.09 Nick Awsomebot is now known as Bensawsome (n=Bensawso@unaffiliated/bensawsome) 03.18.57 Quit saratoga3 ("CGI:IRC (Ping timeout)") 03.19.50 Join beta2k [0] (n=beta@d150-126-240.home.cgocable.net) 03.21.51 Quit jac0b ("Leaving") 03.22.47 # <_hc> saratoga3: any ideas on how hard it would be to get it to boot your own kernel? 03.22.49 # <_hc> or image 03.23.23 *** Saving seen data "./dancer.seen" 03.32.59 Quit Acksaw (Read error: 104 (Connection reset by peer)) 03.33.16 Join Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) 03.33.31 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 03.37.42 Join goffa_ [0] (n=goffa@216.220.23.105) 03.49.54 Quit goffa (Read error: 110 (Connection timed out)) 03.55.12 Join Lambdumb [0] (n=Lambda@12-202-140-90.client.mchsi.com) 03.57.00 # woot I can now read and write rockbox tagcache DBs from python ^___^ Now I just have to make a tag scanner to go with it 04.01.32 Join cool_walking_ [0] (n=anthony@203-59-129-195.perm.iinet.net.au) 04.02.27 Join gaurdro [0] (n=Menschen@unaffiliated/gaurdro) 04.04.09 # reacocard: would you mind sharing the code, I was planning on writing a python script to do the same thing, but haven't gotten very far 04.04.52 Quit Thundercloud (Remote closed the connection) 04.07.51 # perrikwp: its on the wiki, TagcacheDBFormat, the rblib.py attachment 04.08.11 # I've been working on it for a couple weeks now and only managed to crack it today 04.08.53 # still a little rough but it works 04.09.23 Quit jhMikeS (Nick collision from services.) 04.09.29 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 04.10.05 # reacocard: that's great, I have a half-done metadata extracter made with the Mutagen python library 04.10.40 # perrikwp: heh, I have most of one for that already actually. I also dev for the exiale media player and I can adapt the backend without much trouble 04.11.05 # exaile* 04.12.50 # reacocard: thats cool, well I hope you finish soon. Being able to make the rockbox database on the computer will help fix a lot of people's problems 04.13.30 # If all goes well it'll be integrated into exaile 0.3 as well, so it'll be absolutely seamless 04.13.48 # reacocard: great 04.15.03 # but the library itself will of course be available for any open source project to use ^__^ I'd love to see most of the major players give rockbox great support 04.15.37 # reacocard: yeah 04.16.13 Join toffe82_ [0] (n=chatzill@adsl-71-132-86-163.dsl.sntc01.pacbell.net) 04.17.09 # reacocard: i'll be interested in that, i have a python audio conversion/sync suite that already uses mutagen, and i've stalled on adding rockbox DB support for a while 04.18.48 # I'll keep updating the wiki page as I make progress and probably post it to the mailing list when it is complete. So many people have alreayd told me "I'd love osmething like that!" that I really wonder why it hasnt been done before 04.19.26 # I mean its basically undocumented and a little arcane in spots, but its perfectly doable as Ive proved 04.20.11 # undocumented and arcane, that's why. also possibly a lack of one person who was both interested and capable. 04.20.21 # oh ****, the copy on the wiki is bad, one sec 04.21.01 # AUGH it got deleted T__T fortunately its just a few lines I can redo easily 04.24.46 # alright wiki is fixed now 04.25.20 # six lines make a big difference 04.26.09 # if they have the right content, they certainly can 04.27.47 # an entire class 04.28.01 # which contains like 95% of the data 04.28.13 # so yeah 04.31.31 # i actually have a mutagen-based recursive tag scanner, already, but it's tied to a bunch of other transcoding and other manipulation stuff 04.32.15 # yeah. thankfully exaile's is mostly portable. just remove a couple logging statements and change the imports 04.32.37 # at least the 0.3 one is that way. 0.2's is more of a mess 04.32.57 # in fact basically eveythign is more of a mess in 0.2 >.< 04.33.25 Quit jhulst (Read error: 110 (Connection timed out)) 04.33.49 Quit toffe82 (Read error: 110 (Connection timed out)) 04.34.13 # so, rblib.py can't create a DB, at present? 04.34.33 # no 04.35.01 # It can read adn existing one and write it back out. anything else is beyond its capacity 04.35.10 # length is a bit touchy, iirc mutagen rounds to whole seconds for mp3, unless patched 04.35.22 # yeah, ive noticed 04.36.26 # it's rather trivial to fix, and the nature of how the rounding happens looks like a bug to me, so submitting upstream might be fruitful 04.36.38 # indeed, if you can figure out how >.< 04.36.54 # their bugtracker was down last I checked 04.37.03 # oh, ick. :/ 04.37.21 # yeah 04.38.08 # but this is getting somewhat off-topic. less so, it looks like rblib.py completely overwrites an existing database? 04.38.39 # right, but as it parses all the data in from it in the first place you wont lose anything unless you remove it explicitly 04.39.34 # right, but you can insert new Entry items into it, right? 04.39.40 # correct 04.39.46 # or modify the current ones 04.39.49 # or remove them 04.40.19 # so what happens if you create a new Database, don't call read, add some entries, and then try to write? 04.40.38 # s/read/parse/ 04.40.40 # it errors because mmap has no idea what to do with an empty file 04.40.46 # wait 04.40.48 # maybe not 04.40.53 # hm I shoudl try that 04.41.02 # it errors on read if they're empty 04.41.28 # right, but if you init(), and don't parse(), do you have something usable? 04.41.48 # theoretically, as long as you add an entry before you save yes 04.41.49 # could you then add entries and call write()? 04.42.01 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 04.42.15 # so it *could*, theoretically, create a *non*-empty db. we think. 04.42.23 # right 04.42.26 # im going to test that now 04.42.36 # that sounds good enough for the most common needs, to me 04.43.07 # yeah, btu im going to add some other stuff over it bcause this is still really raw access 04.46.03 # the next layer up could optionally hide the error on empty/missing db files, you'd then have something that can transparently create a new DB, assuming that you intend to put songs in it. 04.47.02 # hrm ok in its current form it cant make a new db 04.48.38 # <_hc> anyone using python to write apps/plugins for rockbox? 04.49.12 # _hc: rockbox doesn't run python atm 04.49.13 # _hc: you mean to run inside rockbox itself? that's not going to happen, too much overhead to do 04.49.21 # <_hc> awwww ;) 04.49.35 # <_hc> so basically, only C apps run in Rockbox? 04.49.46 # _hc: pretty much 04.50.34 # Unhelpful: ok I got it to write a new db with a couple minor changes 04.50.43 Join miepchen^schlaf_ [0] (n=miepchen@p54BF6277.dip.t-dialin.net) 04.51.23 # <_hc> which part has too much overhead? 04.51.25 # <_hc> CPU usage? 04.51.33 # <_hc> firmware size? 04.51.35 # memory mroe I think 04.51.40 # _hc: and not really "apps", as most think of them. you can write plugins, and one of them can run at a time, and you can't access the rest of the UI until you exit the plugin 04.51.43 # <_hc> as in RAM 04.51.51 # python uses a lot of mem, and more imporantly allocates it synamically 04.51.52 # _hc: python is an intrepreted language with dynamic memory allocation 04.51.59 # er, dynamically 04.52.47 # _hc: so to be honest depending on the target all of the above, cpu usage, firmware size, runtime memory size, programmer effort, etc. 04.53.17 # <_hc> right, I've run python on embedded systems before: http://www.nytimes.com/2007/10/25/arts/design/25vide.html 04.53.33 # <_hc> this project is 560 arm machines running Python and Pure Data (aka Pd) 04.55.29 Part shyam_k ("ERC Version 5.3 (IRC client for Emacs)") 04.55.47 # yes, but this is an embedded system w/o dynamic allocation. python will be very hard to port w/o a malloc(). if, at some future time, that particular design restriction changes, it could be *possible* to port python 04.55.55 # it may still not be *practical* on some targets 04.56.57 # _hc: rockbox is "extremely embedded", look up the specs on the archos and you'll see what I mean. 04.57.04 # <_hc> I see... those boxes have a 200 Mhz ARM9 and 64MB RAM 04.57.40 # _hc: the wall of news is written in python? 04.57.48 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 04.58.00 # <_hc> python for text and Pd for sound 04.58.06 # <_hc> I did the Pd/sound part 04.58.57 # <_hc> not the composition but the sound setup and programming 04.58.59 # Unhelpful: I've uploaded a version to the wiki that shoudl be capable of making new DBs if you give it an entry 04.59.31 # <_hc> so 8MB of RAM is pretty standard? 05.00.11 # <_hc> we are in the process of porting Pd to Rockbox. It worked on ipodlinux, so rockbox should be possible 05.00.38 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 05.01.11 # _hc: 8mb of RAM? 05.01.50 # <_hc> Llorean: this Archos seems to have 8MB: http://www.archopen.org/tiki-index.php?page=AV3xx_Chipset 05.02.00 # And that's not a Rockbox target. 05.02.11 # <_hc> oh, I see 05.02.25 # Our targets natively have either 2, 16, 32, or 64MB of RAM right now, though there is a mob for 8MB for one of the 2MB targets 05.02.40 # Processor speeds vary greatly, as well 05.02.54 # _hc: http://www.rockbox.org/twiki/bin/view/Main/DeviceChart 05.03.49 # <_hc> luckily, our targets are iPods 05.04.30 # If you're porting something to Rockbox, we ask very strongly that you try to target as many players as possible, at least if you want to contribute it back to us. 05.04.32 # <_hc> hmm, 32MB RAM and 90 Mhz CPU... could maybe eek some thing out with python... any Java/J2ME or Lua possibilities? 05.04.52 # As well, if you want it to run during music playback, you have considerably less than 32MB of RAM available to you. 05.05.05 # <_hc> this is for apps that take over the device 05.05.30 # If you're not interested in preserving music playback, and you only care about iPods, why not stick to iPodLinux then? 05.05.48 # <_hc> doesn't seem to be maintained... the site is down http://ipodlinux.org 05.06.39 # Rockbox isn't designed to be an application platform, so you'll probably encounter more troubles than you would with iPL. 05.06.42 Join wpyh [0] (n=william@71.174.111.248) 05.06.59 # <_hc> or the sourceforge site: Last Update: Nov 22 2004 05.07.19 # As well, plugins have to be compiled against a specific build, so you'll not be able to maintain compatibility with Rockbox unless you just distribute as source, or compile regular builds of your plugin against Rockbox for all the players you wish it to run on. 05.08.16 # <_hc> well for pd, we'd love it to become part of rockbox, but I don't think it would run on less than 16mb RAM... 05.08.39 # Well, many plugins only work on the so called "software codec" players 05.08.53 # Basically, all the players with 16mb+ RAM, at the moment. 05.08.59 # <_hc> is there a HOWTO for makng a plugin? 05.09.02 # <_hc> I couldn't find one 05.09.36 # http://www.rockbox.org/twiki/bin/view/Main/HowtoWritePlugins 05.10.29 # <_hc> bingo, thanks for your help, gotta run now, ttyl 05.12.01 Quit _hc () 05.13.02 # reacocard: excellent, that's enough for me, and probably anybody else who might want to mess w/ the DB from python 05.13.46 # Unhelpful: yeah, from here its just bugfixing and more layers. btu if you want this level of access it'll be there 05.15.02 # reacocard: can you give an example on how to make a new database with one entry. I'm having a little trouble reading the code and seeing how it works. 05.16.25 # perrikwp: d = Database("/some/path"); e = Entry(); e[0] = value, repeat that for all 20 values; d.append(e); d.write() 05.16.48 # reacocard: thanks alot 05.16.53 # no problem 05.17.03 Join Horschti [0] (n=Horscht@p4FD4D3C8.dip.t-dialin.net) 05.17.27 Quit avis (Read error: 110 (Connection timed out)) 05.17.49 Quit Horscht (Nick collision from services.) 05.19.31 # wouldn't be hard to rework Entry to allow passing init data on instantiation 05.19.56 # no not really 05.20.39 # probably I'll let it accept a dict with tag values 05.21.08 # eg Entry( values = {'artist': "James"}) 05.21.15 # something like that 05.23.27 *** Saving seen data "./dancer.seen" 05.23.48 # though, if you have a list already, you could do e[:20] = l 05.24.50 # why not inherit dict, and have it flattened to the right order by Database when it's written? 05.25.36 # given that you have to format it to the rockbox db format, i don't think having to flatten each entry is a big performance hit, especially if you use comprehension or map() 05.25.55 # mm, true 05.26.07 # this was just a first implementation ^__^ 05.26.31 # something like [e.get(t, None) for t in TAGS] 05.26.35 # switching to dict and then just give it a flatten() method even 05.27.09 # that'd work too... is there a single reasonable default you can translate None to for each entry? 05.27.28 # you could always have a DEFAULTS that maps per-field defaults, if not 05.27.29 # no, but its easily delitied into two catagories 05.27.52 # the first 9 shoudl defualt to "", the remainder to 0 05.28.42 # i'd just do a full dict. CPython will likely reuse the key strings, as well as the two values in the DEFAULTS mapping. 05.29.04 # alright, that soudn best so far 05.29.25 # I'll start improving it tomorrow, dont feel like working more tonight :) 05.29.47 # today's task was getting it working which succeeded spectacularly 05.35.39 Quit massiveH ("Leaving") 05.36.03 Join z35 [0] (n=z35@h153.48.117.75.dynamic.ip.windstream.net) 05.36.23 Quit Horschti ("I got raided by the FBI and all i got is this lousy quit message") 05.46.14 Nick miepchen^schlaf_ is now known as miepchen^schlaf (n=miepchen@p54BF6277.dip.t-dialin.net) 05.47.18 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 05.52.22 Quit jhMikeS (Read error: 104 (Connection reset by peer)) 05.54.29 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 06.11.00 Quit massiveH ("Leaving") 06.28.06 # jhMikeS: great work on beast charging. looks like bootloader build is broken, though. trouble seems to be due to bootloader/common.c and firmware/powermgmt.c both defining sys_poweroff and reset_poweroff_timer. 06.28.52 # is one of them supposed to be not built, or not linked, for bootloader? 06.29.24 # a quick read through the patch doesn't show up any obvious change in what goes in bootloader 06.30.58 Join midkay_ [0] (n=midkay@63-231-22-109.tukw.qwest.net) 06.31.36 Quit jhulst (Remote closed the connection) 06.46.02 Quit midkay (Read error: 110 (Connection timed out)) 06.57.30 Join avis [0] (n=ident@pdpc/supporter/student/avis) 07.07.26 Join Lambduh [0] (n=Lambda@12-202-140-90.client.mchsi.com) 07.12.44 Join _hc [0] (n=hanschri@ool-182d0a7f.dyn.optonline.net) 07.20.57 Join Bagderr [241] (n=daniel@rockbox/developer/bagder) 07.21.22 Nick Bagderr is now known as B4gder (n=daniel@rockbox/developer/bagder) 07.23.32 *** Saving seen data "./dancer.seen" 07.24.23 Quit Lambdumb (Read error: 110 (Connection timed out)) 07.37.22 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 07.39.26 Quit phinze (Read error: 110 (Connection timed out)) 07.51.01 Join beta2k_ [0] (n=beta@d150-126-240.home.cgocable.net) 07.54.29 Quit jhMikeS (Nick collision from services.) 07.54.35 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 07.56.53 Quit reacocard (Read error: 110 (Connection timed out)) 07.58.22 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 08.01.38 Quit BHSPitLappy (Remote closed the connection) 08.04.54 Quit beta2k (Read error: 110 (Connection timed out)) 08.08.37 Quit mazling ("Inde da'covale misain ye; Caballien misain ye!") 08.09.15 Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) 08.12.56 Quit massiveH ("Leaving") 08.17.49 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 08.22.54 # hrm, also, looks like something broke at least bootloader usb on beast @ some point. still trying to track it down :/ 08.23.52 # hey, careful, that could be considered helpful ;-P 08.24.10 Part toffe82_ 08.24.20 # fine, i'll stop doing a tedious binary search of subversion revisions? 08.24.55 # if i only had the room to afford a git repo of rockbox on this laptop. and had cloned one, having known i'd need to do this search tonight. :/ 08.25.37 # yeah, binary searches is of course a lot more fun with the entire history stored locally 08.25.53 # and with 'git bisect' too 08.26.43 # B4gder: well, 20/20 hindsight. foresight must need new glasses. 08.28.58 # but i'd say usb or ata is to blame, as i can't even modify the partition table 08.29.46 # Unhelpful: is this with a bootloader built recently ? 08.29.46 # i actually have the "fixed" table saved, so i can slap it on w/ a dd. that doesn't work, so block write is somehow broken. 08.29.56 Quit nuonguy ("This computer has gone to sleep") 08.30.31 # GodEater: that's when it started. i'm down to somewhere between 18324 and 18339 for the start of the trouble, so far 08.31.13 # did you build the bootloader from an unpatched source? 08.31.15 # how is your not being able to modify the MBR manifesting itself ? 08.32.48 Quit _hc () 08.33.30 # initally it was w/ fs #8943 and fs #9312 patches, but i dropped those, still had trouble, went back to 7/14, around when i knew my previous working build to be from, and it was fine, and i've been busy bisecting since then 08.34.03 # GodEater: if i read the "new" MBR from the device, it's not what it read from the device before, but it's not what i wrote to it, either. 08.34.40 # Unhelpful: I can't even get that far - my S complains, and then goes into recovery mode - so I have to re-write an nk.bin to it 08.35.36 # * GodEater wonders where the wiki page went with the rockbox git repo details in it 08.36.31 # i never grabbed the git repo, i only vaguely remember it being mentioned in here 08.36.49 # you could clone it from svn, but that would probably be consider Not Nice, if there's a clone being maintained. 08.39.13 Join Rob2222 [0] (n=Miranda@p4FDCF3F6.dip.t-dialin.net) 08.39.40 # * GodEater prods B4gder 08.39.51 # there is a git mirror 08.40.07 Join freqmod_qu [0] (n=quassel@2001:700:300:1800:213:d3ff:fee9:5ed0) 08.40.23 # but it is hard to find ;-) 08.40.34 # right, which is why cloning it from the svn would be rather rude 08.40.49 # git is designed around cloning the entire history. svn is... not. 08.41.05 # B4gder: didn't we modify the GitVersionControl wiki page with the details of the one you set up ? 08.41.10 # or did we invent a new page ? 08.41.30 # I don't think _I_ edited any page and I'm not sure what anyone else did 08.41.54 # * B4gder checks 08.42.22 # searching only turns up Nico_p's repo 08.42.31 # and I'm not sure he's bothering to keep it up to date these days 08.43.28 # I could have sworn we documented it somewhere 08.44.41 # * GodEater gets his S working again successfully 08.44.48 # this is with a bootloader from yesterday btw 08.45.30 Quit Rob2223 (Read error: 60 (Operation timed out)) 08.47.17 # GodEater: that's including writes from a host PC? 08.47.27 # mine's fine til it write via USB 08.47.46 # well I had to write to it 08.47.57 # so I could mount it, and then unzip a rockbox build to it 08.48.34 # strange. 08.50.19 # my bisect is done, r18237 appears to breaks block write via USB for me. 08.54.58 # i'm going to pull freshest, see if it's still "bad", then reverse just that commit 08.55.29 Quit GodEater ("http://www.mibbit.com ajax IRC Client") 08.57.07 Join GodEater [0] (i=c2cbc962@gateway/web/ajax/mibbit.com/x-8d3ac4673bbc9510) 08.57.11 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.57.46 Join funman [0] (n=tg@82-171-216-191.ip.telfort.nl) 09.05.34 # hmmm 09.05.50 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 09.05.59 # I'd venture to say that perhaps I was a bit quick with the test of LinusN's ata patch yesterday 09.06.06 # it looks like it's hosed the filesystem 09.06.42 # cool! :-) 09.07.08 # reading seems ok - but writing is bad =/ 09.09.15 # GodEater: try w/o the patch. writes corrupt for me w/ r18327 unpatched 09.09.30 # in fact, it seems to have hosed it so bad, I can't even re-create it with mkfs.vfat 09.09.50 # * GodEater will let the OF sort it out 09.10.15 # i have a hard time believing that my patch caused that 09.10.21 # have you ever been able to? i've never been able to give it a format that didn' make the OF force a restore 09.10.42 # I think it's more likely that mkfs.vfat doesn't like the weird partition tabke 09.10.46 # *table 09.11.23 # I guess TFAT and VFAT are sufficiently unalike that the OF can always tell 09.11.23 # possibly 09.11.56 # quite likely. unfortunately, afaik nothing but WinCE itself supports TFAT 09.12.18 # ...and i still think what the tech doc describes sounds a lot like what i remember of Tux2 09.13.07 # ok, if i try to dd my known-good MBR w/ newest svn, i get something on the disk that has a different checksum, and which fdisk does not recognize as having any partitions in it. 09.14.39 # * GodEater tries to copy music over using the bootloader's USB this time 09.16.07 # I wish I could find something which would let me change the damn disk labels - hal keeps mounting both partitions as "TFAT" and "TFAT_" which is a little hard to distinguish on the desktop 09.16.58 # GodEater: add them to fstab, mine mount as /media/gigabeat and /media/gigabeat_boot 09.17.31 # ok, newest is broken for me, newest w/ r18327 reversed works. 09.18.09 # and now the most important question: who is to blame? who committed r18327? 09.18.23 # * GodEater blames perl 09.18.41 # Unhelpful: if I add them to fstab, then hal refuses to automount them 09.19.12 # GodEater: i can never get that HAL stuff to work entirely right, anyway? must be because i use gentoo... 09.19.17 # B4gder: gevaerts did 09.19.57 # well, it looks like the problem it was intended to fix was on e/c200 09.20.13 # And while it seems to fix the problems on PP, it's a fishy one which can very well break usb if it uses dma 09.21.10 # Unhelpful: another reason to give up with gentoo then ;) 09.21.13 # I don't *trust* it on PP either, although I didn't perform tests myself so far 09.22.17 # bah, flipping file not found :/ 09.23.33 *** Saving seen data "./dancer.seen" 09.27.11 # bbiab, rebooting to windows :P 09.29.57 Join Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) 09.35.58 Join funman_ [0] (n=tg@82-171-216-191.ip.telfort.nl) 09.41.22 # *sigh* that fixed "file not found" before. i know somebody else said that repeatedly repeatedly recovering their beast made it go away :/ 09.42.42 # i wonder if that has anything to do w/ the oddities of TFAT 09.42.55 Join Zom [0] (n=zom@h81172159115.kund.kommunicera.umea.se) 09.47.08 Quit Xerion (Read error: 110 (Connection timed out)) 09.47.08 Nick Xerion_ is now known as Xerion (i=xerion@82-170-197-160.ip.telfort.nl) 09.47.57 Quit funman (Read error: 110 (Connection timed out)) 09.52.29 # http://paste.ubuntu.com/41152/ 09.52.47 # I use this patch on apps/plugins/mp3_encoder.c to be able to use it in the simulator 09.53.06 # on x86_64, sizeof(long)==8 so it can not be used to cast a char[4] 09.53.30 # uh, nasty typecast 09.54.13 # I would compare each char one by one, the code using it doesn't need critical speed 09.54.34 # could use uint32_t, or int32_t 09.54.35 # the code assumes that string is aligned too 09.54.44 # but I bet it always is 09.55.09 # memcmp should be used imho 09.55.16 # the string is on the stack 09.55.38 # the string pointer is, yes 09.56.00 # what about for(i=0;i<4;i++) ? 09.56.19 # it adds no dependancy 09.56.25 # the string itself could *possibly* be. i'm sure if you pass the pointer somewhere, gcc will make sure the string is in memory. 09.56.38 # memcmp() exists in the plugin api already 09.56.48 # ok 09.58.06 # return !rb->memcmp(tmp, string, 4); perhaps ? 10.00.57 # uh temp, not tmp 10.01.01 # GodEater: hey, i got mkdosfs to work. and it seems to reliably avoid the beast file-not-found error. 10.02.00 # B4gder: indeed, it runs fine 10.02.15 # I'll commit that then, thanks! 10.02.43 # you're welcome, that's a small contribution .. 10.03.00 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 10.03.11 # I would rather submit you with some code for e200v2 :P 10.03.36 # haha, yes please! ;-) 10.08.42 # for any other S owners, i used mkdosfs -f 2 -F 32 -S 512 -s 64 -n TFAT 10.09.14 # i tried using smaller clusters, but that made the OF format it again for me 10.09.29 Join pixelma [50] (i=pixelma@rockbox/staff/pixelma) 10.10.56 # cluster is the minimum allocation unit for FAT, isn't it? makes it kind of a shame that 32K clusters seem to be required. 10.35.36 # Unhelpful: could you add that to the wiki please ? 10.36.19 # erm, i can't at present, on account of not having requested write access as of yet. 10.40.28 # whenever somebody can grant write access to AndrewMahone, i'll be happy to add it... i'd guess to GigabeatSInstallation? 10.40.43 # gevaerts: did you spot your blamage for the beast problems? 10.41.23 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 10.41.47 Quit amiconn (Nick collision from services.) 10.41.53 Join amiconn [50] (n=jens@rockbox/developer/amiconn) 10.41.54 # B4gder: yes. I'll look at it in detail later, but beast owners should be able to just revert usb_storage.c to r18326 10.43.23 # let me know if there's anything i can do, testing-wise. i'll need to reload music on it, anyway, this weekend, so risking FS corruption is not a big deal - but maybe there'd be some handy way to figure out where the data that *does* get written is coming from? 10.44.03 # Right now, nowhere (I forgot to initialise a pointer on non-PP) 10.45.39 # http://pastebin.ca/1187204 should fix it 10.45.48 # oh, my, i'm stupid. no wonder MikeS's shiny new charging code isn't working... had the battery switch off while bisecting. 10.45.56 # (totally untested, hopefully it compiles) 10.46.02 # heh. 10.47.08 # i have a bit of work to get through here, then i can build+test 10.52.17 # anything preventing recording from mic/fm in the simulator, besides "not tested" ? 10.52.40 # you missed a semicolon in the first inserted line. fixed that and compiles. now really going to do work... 10.53.51 # * gevaerts pretends to have done that on purpose to avoid nontechnical people trying out potentially dangerous patches 10.58.32 # this really shouldn't be more interesting than work. passes trivial write test. writing-from-data-at-uninitialized-pointer must be fixed, that was, um, kind of obvious, when it happened. 11.00.30 # * gevaerts will commit. The fix is probably not the cleanest possible, but then the cached/uncached thing also isn't 11.02.18 Quit cool_walking_ (Remote closed the connection) 11.02.47 Quit linuxstb (Read error: 110 (Connection timed out)) 11.02.59 # gevaerts: Imho the whole cached write buffer thing should be reverted except for sansa, complete with a big warning comment that this is fishy 11.03.02 Join DerDome [0] (n=DerDome@dslb-082-083-200-021.pools.arcor-ip.net) 11.03.51 # amiconn: I agree. I'll do that tonight 11.12.23 Join MartinR [0] (n=chatzill@dslb-088-072-228-142.pools.arcor-ip.net) 11.13.17 # gevaerts: I really think the sansa bug should be fixed (worked around) at the driver side, not at the USB side. 11.13.40 # gevaerts: Calculating the cached address would be easy, but I'm uncertain about the cache handling. 11.14.09 # Bagder: did you already have a chance to see what's up with the coldfire and sh daily builds? 11.14.25 # is there a problem? 11.17.09 # MartinR: you're probably right, and the cache thing is probably only a way to hide the real reason (timing issues). I'm not really at home in the driver though, and I think that any change there should wait to after 3.0 before it's committed 11.18.01 # do we use the driver for anything in the 3.0 targets? 11.18.35 # pixelma: what's the problem with the daily builds? 11.18.37 # I mean the sd driver. This is the corruption issue 11.18.46 # So yes, we use that 11.18.48 # aha 11.19.09 Join snoh [0] (n=dave@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) 11.19.11 # if the sd driver corrupts the file system, i consider it a 3.0 showstopper 11.19.12 # LinusN: yes, look at the size of the zips (sh is at least missing the .rock files, coldfire the .rocks and the codecs (and the rockbox.info file). And while the package size looks correctly, I get a "zip not found on this server" when trying to download the latest e/c200 daily 11.19.42 # gevaerts: Yes, this should wait until after 3.0. Maybe even reverting the whole cache thing would be the best for now. 11.20.03 # LinusN: it only does it when used from the usb stack. Nobody has yet seen any issue within rockbox 11.20.05 # pixelma: ah, now i see, i was looking at the wrong builds 11.20.21 # gevaerts: aha, i see 11.20.30 # LinusN: and if you look at the table, it seems quite obvious that it started with the server crash 11.21.02 # Bagder already tried some things which brought back parts of it 11.21.27 # LinusN: The sd driver occasionally corrupts data when writing. Changing the write loop changes the frequency of that happening 11.21.39 # LinusN: (like e.g. the voice files which were missing at the beginning too) 11.21.46 # I guess there's some register we're not setting correctly 11.21.55 # amiconn: so it could happen when recording as well? 11.22.02 # * gevaerts hopes that LinusN is good at talking about two things at the same time 11.22.09 # :-) 11.23.34 *** Saving seen data "./dancer.seen" 11.24.54 # LinusN: It can basically happen any time. Not only when recording, but also when saving playlists, or .playlist_control etc 11.25.15 # ah, of course 11.25.59 # But I don't think anyone actually has seen it happen verifyably with a clean svn build for anything but usb writes 11.26.07 # didn't someone test writing (copy+pasting inside Rockbox)? But maybe that was with some patch, don't remember exactly... :\ 11.26.53 # pixelma: yes. I've basically asked everyone who reported corruption on usb write to test that. Nobody had any issues there 11.27.47 # Also boosted? 11.28.23 # * gevaerts checks the FS#8663 log 11.29.03 # When experimenting with an optimised write loop, it worked nicely at 30MHz, but caused problems at 80MHz 11.29.12 # pixelma: bug found - rebuilding dailies 11.29.19 # amiconn: Yes, I also tried copying when boosted. No cooruption. 11.30.26 # How much data did you try? 11.30.59 # * MartinR checks the FS#8663 log :) 11.31.24 # Could you compile the test_disk plugin and run that (boost before)? That one writes 300MB (make sure you have that much free space internally) and then verifies it 11.31.45 # You can also modify test_disk to use the sd card 11.32.35 # LinusN: nice, thanks :) 11.32.55 # no, thank *you* for reporting :-) 11.33.42 # I used a directory of 415 MB (95 files) then. But will try test_disk soon. 11.36.23 # But I think it's rather coincidence that the bug does not appear on internal operations. 11.37.52 # If that udelay is changed slightly, it does also then. 11.38.27 # Yes, and that's what makes me think there's something fundamentally wrong 11.39.20 # would some logic analysis help? 11.39.49 # or is it internal, like a caching issue? 11.41.58 Join n1s [0] (n=nils@rockbox/developer/n1s) 11.43.58 # Hard to say what kind of issue this might be. 11.43.58 # jhMikeS: thanks much for the charging code. seems to work for me, but i haven't had a chance to *really* run down the battery yet. 11.44.13 # I think internal copying works because it's a tight loop that doesn't get interrupted by anything, so you get predictable timings 11.44.46 # test_disk is basically the same there, but both usb and recording are more complex 11.45.01 # LinusN: I think it's a timing issue. We need to find the missing register setting(s) 11.45.26 # So I suspect that if we see corruption without usb, it will be while recording (or maybe with playlists) 11.47.52 # I already poked around in the bootloader code, but found nothing that we're missing. 11.48.42 # Though, rockbox is doing some things in a different order. 11.48.49 Quit bughunter2 (Read error: 104 (Connection reset by peer)) 11.49.39 Join [CBR]Unspoken|w [0] (n=cbr@212.98.160.130) 11.50.11 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 11.51.01 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 11.54.49 Join mf0102 [0] (n=michi@85-127-21-119.dynamic.xdsl-line.inode.at) 11.58.51 # That's only the bootloader though. Do we know if the OF sd driver is in iram, if the data is in iram, ... ? 12.06.29 # Wasn't able to find out that. I'm still a rookie on ARM. But it seems that the OF makes heavy use of IRAM. There are many hard coded IRAM adresses. 12.09.23 # Actually, I didn't find any sd related code in the OF. It seems to use the driver inside the bootloader. 12.14.18 Join kerrorizer [0] (n=58d4014d@gateway/web/cgi-irc/labb.contactor.se/x-4146f7ad18e9694d) 12.14.33 # hello gyus can someone help me ? 12.14.50 # i want to ask where will be able ROCKBOX for CREATIVE ZEN 12.15.30 Quit kerrorizer (Client Quit) 12.18.20 # now that's some patience :) 12.18.45 # we'd only have told him to bugger off anyway ;) 12.27.40 Join mf0102_ [0] (n=michi@85-127-21-119.dynamic.xdsl-line.inode.at) 12.27.40 Quit mf0102 (Read error: 104 (Connection reset by peer)) 12.30.33 Join aart3k [0] (n=aart3k@78.131.137.50) 12.31.15 # hi 12.31.45 # does Rockbox still work with compactflash based ipods? 12.31.56 Quit Seed ("cu, Andre") 12.32.10 # should do 12.32.14 # for me bootloader doesn't work on 2g mini with 8gb cf 12.32.20 # by transcend 12.32.26 # original firmware works 12.32.30 # well the cards have seemed to vary a lot 12.32.55 # it seems that bootloader is unable to mount partitions 12.33.31 # hm.... 12.33.44 # if the OF works, then there must be a bug IMO 12.33.53 # No partition found 12.34.03 # yeah 12.34.17 # aart3k: You may need to compile your own bootloader from SVN, I'm not sure if the changes to support CF cards are in the last released bootloader. 12.34.21 # disk_mount_all() gives zero or something, i didnt debug 12.34.55 # linuxstb: does the build for the mini include FAT32 support? 12.35.06 # but it should... hm... 12.35.25 # diff that i've found on wiki doesn't seem to be useful with stuff that bootloader uses 12.35.39 # so i didnt compile 12.36.03 # uh... seems the other way around 12.36.07 # wpyh: All builds contain FAT32. FAT16 is only enabled on some targets - search the config-*.h files to see for which ones. 12.36.24 # (I'm talking to myself) 12.36.34 # linuxstb: yeah, I got it reversed 12.36.47 # aart3k: did you format it as FAT16 or as FAT32? 12.37.34 # You cannot format 8GB as fat16 12.37.41 # fat32 12.38.14 # i've just restored it using itunes 12.38.21 # amiconn has a point 12.39.02 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 12.39.08 # well, aart3k, what I would do is insert something like printf() statements before and inside disk_mount_all() 12.39.18 Quit XavierGr (Nick collision from services.) 12.39.28 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 12.40.20 # so i need to debug by myself 12.40.25 # damn ;) 12.41.17 # i'll be back at evening, maybe i'll see some results 12.41.33 # but first of all i'll try to format patrition as fat16 12.41.51 # anyways seeya guys, thanks for helping 12.42.38 # aart3k: formatting as fat16 won't work... 12.43.12 Part aart3k 12.46.00 Join krz_ [0] (n=chatzill@mail.jvl.by) 12.46.46 Join faemir [0] (n=faemir@88-106-209-242.dynamic.dsl.as9105.com) 12.46.59 # heloo all 12.47.07 # *hello :) 12.53.29 Join ZincAlloy [0] (n=d9eee040@gateway/web/cgi-irc/labb.contactor.se/x-6f12471e39a7b8f3) 12.54.15 # are there any of SVN admins? 12.54.33 # krz_: What do you need? 12.55.55 # linuxstb: so, wpseditor almost ready to be commited to svn. my mentor said that one of admins can create a branch for it 12.56.24 # so there's an updated patch in the tracker? 12.58.43 # krz_: Does your patch make many changes to the core Rockbox code? 12.59.00 # * linuxstb goes to find the patch 12.59.21 # B4gder: no updates from yesterday 12.59.53 Quit funman_ (Read error: 104 (Connection reset by peer)) 13.00.05 Join moos [0] (i=moos@81-66-127-205.rev.numericable.fr) 13.00.13 # linuxstb: there are some changes made via ifdefs. it was tested on rockbox build and seems that it doesnt breack anything 13.00.24 # krz_: Looking at your patch quickly now, you're making unwanted whitespace changes - e.g. doing things like "# define" (adding spaces) 13.01.10 # linuxstb: so, this is unwanted? it helps great to read the code 13.01.23 # Read the coding guidelines in docs/CONTRIBUTING 13.01.35 # unrelated changes are always bad 13.01.44 # linuxstb: anything else? 13.01.45 # since it makes reading the patch harder 13.01.45 # The basic principle is to always keep the formatting the same as the file you're editing. 13.02.02 # what's the fs#? 13.02.06 # And as B4gder said, don't include whitespace changes in functional patches 13.02.10 # 9327 13.02.22 Join funman [0] (n=tg@82-171-216-191.ip.telfort.nl) 13.03.01 # i.e. if you want to make whitespace changes, make a patch with only whitespace changes. 13.03.33 # I can see tabs in the code 13.05.20 # and what about code changes? 13.07.17 # krz_: It's hard to tell, because of all the whitespace changes also included in the patch. Can you fix that, and post a new version of "rb_changes2.patch", with only functional changes? 13.07.42 # linuxstb: ok,sure 13.07.43 Join funman_ [0] (n=tg@82-171-216-191.ip.telfort.nl) 13.07.45 # And have you checked that the standalone checkwps tools still work OK? 13.10.00 Quit funman (Read error: 104 (Connection reset by peer)) 13.10.51 # as my mentor said - it will no longer be needed, caouse wpseditor has all of it functionnality. concering your question - no, i haven't checked yet 13.11.07 # it will be needed 13.11.20 # wpseditor is a gui program, checkwps can be run without ui 13.11.54 Nick Kopfi|offline is now known as Kopfgeldjaeger (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 13.14.04 # checkwps will be used on the new themes site for validating uploaded themes... 13.23.36 *** Saving seen data "./dancer.seen" 13.23.45 Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 13.28.51 Join Lambdumb [0] (n=Lambda@12-202-140-90.client.mchsi.com) 13.30.15 # linuxstb: there is also a branch on wpseditor - a screenshot utility, which can be ran from console to create a screenshot of new theme(thanks to Maurus). basically this feature can be added to wpseditor. and while making screenshot we can validate new theme 13.37.21 Quit faemir ("Leaving") 13.38.43 Quit goffa_ (Read error: 60 (Operation timed out)) 13.39.36 Quit jhMikeS (Nick collision from services.) 13.39.42 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 13.41.43 # LinusN: that post of yours could do with some tidying up ;) 13.42.00 Join goffa [0] (n=goffa@216.220.23.105) 13.42.02 # Looks impressive though :) 13.42.08 # yes 13.46.06 Quit Lambduh (Read error: 110 (Connection timed out)) 13.46.42 # * GodEater tidies it up for LinusN 13.50.19 Join virtuoso015 [0] (n=vinay@59.96.63.57) 13.51.53 Join kugel [0] (n=chatzill@unaffiliated/kugel) 13.53.18 Join super [0] (i=super@c80-217-108-79.bredband.comhem.se) 13.53.50 # Slasheri: ping 13.54.24 Join dabujo [0] (i=xx@p4FDB3242.dip0.t-ipconnect.de) 13.59.44 Join goffa_ [0] (n=goffa@216.220.23.105) 14.01.18 Join parafin|away [0] (i=parafin@parafin.dialup.corbina.ru) 14.02.06 Quit parafin (Nick collision from services.) 14.02.08 Nick parafin|away is now known as parafin (i=parafin@parafin.dialup.corbina.ru) 14.04.52 Join super_ [0] (i=super@c80-217-108-79.bredband.comhem.se) 14.05.53 Join Nico_P [0] (i=53915df2@gateway/web/ajax/mibbit.com/x-043bbdf97197ece3) 14.07.33 # linuxstb: hi, are yo still interested in the buffering-on-flash patch? 14.07.45 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 14.08.08 # Nico_P: I'm curious about it... e.g. to see how it affects runtime on a current target. 14.08.46 # I improved it about a week ago, it seems pretty usable now 14.10.39 Quit super (Read error: 110 (Connection timed out)) 14.10.42 Quit parafin ("So long and thanks for all the fish") 14.10.45 Join parafin [0] (i=parafin@paraf.in) 14.11.40 Quit goffa (Read error: 110 (Connection timed out)) 14.11.47 # linuxstb: so, what do you think about making wpseditor to run from console like checkwps? 14.15.10 # Sounds like it could be useful, but I would concentrate on the core functionality for now - checkwps does the job of validating a wps already. 14.15.53 # linuxstb: http://pastebin.ca/1180832 in case you want to give it a try 14.16.22 # Nico_P: I don't have time to test things at the moment (and I think I'm catching JdGordon's flu...), but would be curious if someone else did a runtime test... 14.17.13 # linuxstb: I think I'll put it up on flyspray so that someone can maybe do a runtime test 14.17.50 # How much RAM does it use? What about storing metadata? 14.17.55 # (and album-art?) 14.18.54 # album art won't work. there are a few static buffers for metadata, and it uses a 32K buffer (the max size of a chunk) for audio data 14.19.49 # if we assume the patch is meant to be used for lowmem targets, I don't think we'll want album art 14.21.01 # If it doesn't have too many disadvantages, you could also use it to increase the plugin RAM a lot 14.22.10 # it would sure be nice to know what kind of impact it has on runtime 14.29.16 # linuxstb: it seems that checkwps utility wasn'thecked for a log time :) there were errors. i can include fixes in rb_changes.patch 14.29.57 # btw checkwps doesn't compile for cowon and mrobe500 14.30.16 # Yes, that's known - but they are not supported targets yet, so it's not very important. 14.30.32 Quit Zom ("leaving") 14.30.48 # If you have fixes to checkwps, it would be better to create a separate patch just for that. 14.31.06 Join Zom [0] (n=zom@c-73b9e253.09-109-73766c10.cust.bredbandsbolaget.se) 14.31.08 # * Nico_P has created FS#9332 14.31.48 # we should perhaps build checkwps for the specific target as part of the normal build 14.32.03 # that will make sure it remains building 14.32.16 # buildable I mean 14.33.31 # it doesn't build for all targs now. on mingw at least 14.33.44 # yeps, I noticed that too 14.34.02 # BOM_SIZE, BOM and SEEK_SET undeclared 14.34.33 Quit gaurdro (Read error: 113 (No route to host)) 14.34.50 Nick super_ is now known as super (i=super@c80-217-108-79.bredband.comhem.se) 14.36.41 # Do you think moving BOM_SIZE and BOM into misc.c is the right fix? afiacs, they're not used outside that single function. 14.37.00 # then that sounds reasonable, yes 14.37.06 # linuxstb: fs9327 here is rockbox_changes3 14.37.19 # btw it includes fixes for checkwps 14.37.20 # OK, I'll commit that. 14.37.32 # I meant moving BOM_SIZE and BOM into misc.c... 14.38.30 # we can only to include misc.h for __PCTOOL__ 14.45.23 Part B4gder 14.47.31 Quit MartinR (Read error: 110 (Connection timed out)) 14.48.04 Quit Seed ("cu, Andre") 14.51.43 # krz_: I've just committed a fix for checkwps - thanks for mentioning it was broken. 14.53.16 Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-f164af6ce7d88449) 14.54.51 # krz_: Looking at your latest patch, it's getting nice and small now :) But there are a few minor things - e.g. using #if defined() instead of #ifdef (you sometimes use one, sometimes the other...) 14.55.28 # linuxstb: il make if defined then :) 14.55.35 # *i'll 14.56.02 # krz_: is it a gsoc project? 14.56.15 # kugel: yes 14.56.43 # Also, in wps_parser.c, you've added a lot of #includes of standard Rockbox headers for WPSEDITOR only. I think those could be included for normal Rockbox builds as well - it's just luck that they're included by other .h files already. 14.56.52 # krz_: #ifdef is more commonly used in Rockbox source... 14.58.28 # krz_: Your files are lacking some rockbox headers imho ;) 14.59.19 Join JUSTWJX [0] (n=79e8e47c@gateway/web/cgi-irc/labb.contactor.se/x-d2bfc0b79d4ab41f) 14.59.19 Join reacocard [0] (n=reacocar@rccy-06-1010.dsl.iowatelecom.net) 14.59.41 # linuxstb: so, you think they can be included not only in ifdef __PCTOOL__? 15.00.03 # krz_: Yes, I think so. 15.00.26 # markun,what's going on with meizu M6? 15.00.39 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 15.03.24 # krz_: I wonder why you have your own checkwps in the editor, is the rockbox one not good? 15.03.41 # :-( 15.04.39 # JUSTWJX: Please don't ask for progress reports here. Everything that happens is reported on the forums. 15.04.48 # kugel: it is a bit different 15.05.13 # krz_: Has it the same purpose? 15.06.05 # right~ 15.06.27 Join phinze [0] (n=phinze@pool-96-250-252-230.nycmny.fios.verizon.net) 15.06.28 # kugel: i've reimplemened some functions from original checkwps 15.06.56 # krz_: if yes, I say rather fix the existing checkwps, if not, i say give it a different name 15.07.26 Quit JUSTWJX ("CGI:IRC (EOF)") 15.08.51 Quit nplus (Remote closed the connection) 15.09.40 # krz_: So, what's the difference between your and the normal checkwps? 15.10.49 # kugel: as i have said i've reimplemened some functions from original checkwps. and i use some of the original ones 15.11.59 # krz_: I've read that. I wonder why you made another one, so I asked you what the differences are 15.12.40 # kugel: i mentioned the difference 15.13.47 # krz_: not really. You said that there is one, not why 15.15.01 # gevaerts: i don't understand, what do you want to hear 15.15.03 Join nplus [0] (n=nplus@141.25.Globcom.Net) 15.15.06 # " i've reimplemened some functions" is hardly a meaningful difference for me 15.15.34 # krz_: What can your checkwps do what the original one can't, and vice-versa 15.16.21 Join Thundercloud_ [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 15.18.00 Part swimmer ("[IRSSI] Should I do my BOBBIE VINTON medley?") 15.18.32 Join swimmer [0] (n=swimmer@95-50-223.ftth.xms.internl.net) 15.21.04 # kugel: i don't use it now for checking wps. 15.21.45 # krz_: What? You didn't answer my question: What can your checkwps do what the original one can't, and vice-versa? 15.23.40 *** Saving seen data "./dancer.seen" 15.23.44 # kugel: i don't use function checkwps at all now. mechanism for loading wps's was based on checkwps. so, if you don't like the name - a can rename it 15.24.37 # So, it has a different purpose? That at least answers my initial question 15.25.02 # krz_: if you have a checkwps function that doesn't check a wps, then yes, please rename it 15.25.45 # kugel: no, it doesn't have a different propose 15.26.48 # So it has the same purpose? 15.27.52 # yes 15.27.56 # You reimplement checkwps, with the same purpose (and don't even use it) rather then makeing the existing fit your needs? 15.28.10 Join funman [0] (n=tg@82-171-216-191.ip.telfort.nl) 15.28.11 # that doesn't make sense to me 15.28.16 Quit funman_ (Read error: 104 (Connection reset by peer)) 15.28.59 # i've reimplemented not checkwps, but other functions from checkwps.c. and function "checkwps()" can be used in gui 15.29.51 Quit Thundercloud (Read error: 110 (Connection timed out)) 15.31.44 # krz_: As long as your version of checkwps says "yes the wps is fine" or "no, the wps is broken", use the existing one 15.34.43 # kugel: so, you propose to include original checkwps.c to my build? 15.35.10 # yes, either build-in or as an external app called by your editor 15.36.57 # so, don't you think that linker will give errors when he meets my iplementations of some funcs and original one from checkwps.c? 15.40.50 # I don't know 15.43.25 # krz_: I see it as design flaw when your wps editor and checkwps are incompatible 15.44.46 Quit virtuoso015 (Read error: 60 (Operation timed out)) 15.44.52 # krz_: easy. Either split checkwps.c in two files, or use ifdefs. I would personally prefer splitting 15.45.29 Part swimmer ("[IRSSI] 1 oz. vodka") 15.45.30 # * kugel would prefer #ifdef'ing, as checkwps.c already a tiny file 15.45.45 # size has nothing to do with it 15.45.55 # kugel: so, linker will give errors 15.46.28 # surely i can make ifdefs 15.46.30 Join swimmer [0] (n=swimmer@95-50-223.ftth.xms.internl.net) 15.46.41 Quit swimmer (Client Quit) 15.46.42 Join PaulJam [0] (n=PaulJam_@p54BCCE04.dip.t-dialin.net) 15.47.46 Join swimmer [0] (n=swimmer@95-50-223.ftth.xms.internl.net) 15.48.11 # * linuxstb doesn't see it as a problem that wpseditor is copying some things from checkwps - using tools/checkwps/checkwps.c directly in wpseditor seems messy. 15.48.36 # linuxstb: thanks :) 15.48.55 # krz_: You can also consider build checkwps seperately and using it as an external app, or is this not possible? I think this is preferable, since checkwps features batch checking, so it'd be possible to check more wps files than the one in the editor 15.49.03 # But maybe the common code from wpseditor and checkwps could be factored out to a common place... 15.49.41 # libwps ? 15.49.42 # :) 15.50.12 # linuxstb: I see the problem of maintaining two things with the same purpose 15.50.12 Quit XavierGr (Read error: 104 (Connection reset by peer)) 15.51.34 # so 15.52.04 # krz_: How do you find my proposal? 15.52.06 # should i refactor or leave all behind? 15.54.19 # kugel: i'd perefer not to make it complex 15.55.08 # krz_: calling an external app is complex? 15.55.38 # kugel: it's not necessairly easily portable 15.56.08 # * gevaerts would prefer these tools not to depend on calling external apps 15.56.50 Join Lambdugh [0] (n=Lambda@12-202-140-90.client.mchsi.com) 15.58.14 # wpseditor->emacs :) 15.58.29 # krz_: Refactoring would be nice, but IMO it's not vital before it can be committed. It may turn out that wpseditor will replace checkwps, in which case the problem disappears... 15.58.56 Join virtuoso015 [0] (n=vinay@59.92.188.5) 15.59.13 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 15.59.52 # linuxstb: but then the wps editor should at least offer a llittle cli to check wpses (for the theme site) 15.59.59 # linuxstb: as i mentioned above, it can replace checkwps 16.00.15 # kugel: sure, but that's not infeasible 16.00.49 # gevaerts: yea, I could live with it then :) 16.01.22 # so... are current changes acceptable? 16.04.11 # from what I've understand: no, but this can be done after committing 16.05.33 # krz_: you'll never get a total consensus on this, so if I were you I'd mainly listen to domonoky (as he's your mentor) and linuxstb (as he's the main checkwps guy) 16.05.47 Quit z35 (Read error: 110 (Connection timed out)) 16.07.48 Part LinusN 16.07.59 # as far as i understood from today's talk, in near future wpseditor can replace checkwps(or can be refactored) 16.08.09 # but what are te oher problems? 16.12.07 # krz_: I noticed that you disable all of dircache.h for wpseditor. Wouldn't it be better to make the actual include conditional? 16.12.40 # gevaerts: you mean in makefile? 16.15.05 Join _hc [0] (n=hanschri@ool-182d0a7f.dyn.optonline.net) 16.15.12 # krz_: actually, I'm looking now. Whyni 16.15.31 # Why is the #if !defined(WPSEDITOR) in dircache.h needed? 16.17.00 Quit Nico_P ("http://www.mibbit.com ajax IRC Client") 16.17.26 # gevaerts: actually i don't need all that funcs in wpseditor, and i didn't want to include additional headers 16.17.57 # krz_: #ifdefs are basically ugly, so you don't use them if you don't need them 16.18.00 Quit Lambdumb (Read error: 110 (Connection timed out)) 16.18.11 # Also (others may disagree here) I prefer a "defined but not used" warning over #ifdeffing out a static function. 16.18.47 # * gevaerts refers to long2bytes() in mp3data.c 16.19.42 # :) i tried to remove all warnings, cause someone complained on it yesterday 16.20.01 # and today you say that it was ok 16.20.03 # That's probably the "others may disagree" bit :) 16.20.11 # :) 16.20.26 # i'll wait for my mentor i think 16.21.15 Quit wpyh ("Leaving.") 16.21.55 # gevaerts: That's not really practical, as we want to squash all warnings... 16.21.56 # One other thing : please go over the diff line by line for existing files. You'll then see unneeded changes (like #ifdef __PCTOOL__ to #if defined(__PCTOOL__) in wps_debug.c). Try to sort those out. All that just makes reviewing this harder 16.23.21 # linuxstb: i'd also like to hear your opinion about all this 16.23.55 # linuxstb: I mostly agree, but usually not for "defined but not used" warnings. Adding #ifdefs for those just clutters up the code 16.25.35 # krz_: in the long2bytes() case in mp3data.c, just move the #ifndef __PCTOOL__ up a bit to start just before long2bytes(). That should solve it 16.27.25 # gevaerts: jup 16.30.18 Quit funman (Read error: 110 (Connection timed out)) 16.31.52 Quit EspeonEefi ("さよなら") 16.34.19 # krz_: maybe upload a new patch to the tracker with all fixes (as soon as you've made them). That will make it a lot easier 16.35.13 # gevaerts: just did it :) 16.35.47 Nick krz_ is now known as krz|afk (n=chatzill@mail.jvl.by) 16.38.47 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 16.39.26 Join Nibbler [0] (n=Nibbler@91-67-150-33-dynip.superkabel.de) 16.42.14 Join Nico_P [0] (i=53915df2@gateway/web/ajax/mibbit.com/x-33624d5c44ca138c) 16.47.12 Quit virtuoso015 (Read error: 110 (Connection timed out)) 16.47.22 Join virtuoso015 [0] (n=vinay@59.92.174.27) 16.48.18 Quit moos ("Rockbox rules the DAP world") 16.48.22 Join moos [0] (i=moos@81-66-127-205.rev.numericable.fr) 16.48.54 Quit Nibbler (Read error: 113 (No route to host)) 16.52.43 Join Pegasus_ [0] (n=Pegasus@felix.csn.tu-chemnitz.de) 16.53.41 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 16.54.35 Nick krz|afk is now known as krz_ (n=chatzill@mail.jvl.by) 16.54.46 # krz|afk: nearly there :) I have one issue left with the changes to existing code : In firmware/font.c the indentation of glyph_file = creat(GLYPH_CACHE_FILE) is wrong 16.55.15 Quit mf0102_ ("Ex-Chat") 16.56.34 # gevaerts: They're tabs... 16.56.41 # oops 16.56.48 # <_emp> linuxstb, I got openBSD working. 16.57.23 # _emp: Nice. Do you have a patch? 16.57.44 # <_emp> linuxstb, http://www.rockbox.org/tracker/task/9330 16.58.25 # <_emp> linuxstb, I need to help wrapping it up. I want to re-write the geometry stuff, rather than just doing the overwrite as found in those patches. 16.58.39 # <_emp> linuxstb, and I assumed a blocked device. 16.58.48 # * gevaerts spots tabs in time.h in svn 16.59.07 # gevaerts: fixed, new patch is coming .. :) 16.59.56 # gevaerts: kill, kill, kill... 17.00.11 # btw, why does everyone so dislike tabs? 17.00.54 # It's not so much disliking tabs as wanting consistency 17.01.01 Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) 17.01.09 # Because they're very easily misused. Using tabs assumes everyone (and every editor) will handle them correctly. 17.02.44 # <_emp> gotta run, bbl 17.03.28 # krz_: I also think there are more #ifs that you can remove - i.e. include the extra include files always, not just for WPSEDITOR. It makes the code cleaner. 17.03.30 # * gevaerts spots tabs in 276 .c and .h files 17.03.53 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-7ac17b6f11329f81) 17.04.36 # saratoga: Do you know if anyone will be doing your final evaluation for SoC? JdGordon said yesterday that he was too ill to do it... 17.05.05 # linuxstb: I have not heard anything about that 17.06.15 # saratoga: See here - http://www.rockbox.org/irc/log-20080827#09:13:44 17.06.46 # linuxstb: how is eligable to write the evalutation? 17.06.53 # who 17.07.08 # I've no idea... 17.07.14 Join Nibbler [0] (n=Nibbler@91-67-150-33-dynip.superkabel.de) 17.08.01 # You didn't have a backup mentor... 17.09.02 # can one of the other mentor's evalutate me? 17.09.55 # * linuxstb wonders if Bagder or scorche|sh or scorche knows 17.18.56 # has anyone tried my mp3 COP patch on an Ipod Video? llorean suggested it might be neat to see what it does to UI responsiveness 17.19.31 # saratoga: Not yet; what's the FS#? 17.20.23 # FS#9318 17.22.45 # i think it should save a good bit of battery lfie 17.23.25 # I'll try it out later. 17.23.41 *** Saving seen data "./dancer.seen" 17.24.55 Quit moos ("Rockbox rules the DAP world") 17.33.34 # saratoga: any known issues except the test_codec one? 17.34.06 Join jgarvey [0] (n=jgarvey@cpe-098-026-069-229.nc.res.rr.com) 17.37.52 Quit Horscht ("User was distributing pornography on server; system seized by FBI") 17.38.04 # * krz_ uploaded new patch 17.38.22 # * krz_ thinks no more ifdefs could be successfully removed 17.44.44 Nick krz_ is now known as krz|afk (n=chatzill@mail.jvl.by) 17.48.32 # Hmm, how to build the wps editor? 17.50.32 # krz|afk: ^ 17.52.52 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 17.52.56 Quit Horscht (Read error: 104 (Connection reset by peer)) 17.56.02 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 18.04.39 # I guess I compiled it, but I cannot run it...libproxy.so not found... 18.04.55 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 18.08.52 Join perrikwp [0] (i=d1a8d351@gateway/web/ajax/mibbit.com/x-58d09d60929ec3da) 18.09.03 Join waldo [0] (n=waldo@ip-81-11-204-148.dsl.scarlet.be) 18.10.25 # gevaerts, linuxstb: can you help? 18.12.52 Join fragilematter [0] (n=barbu_do@92.82.110.115) 18.14.57 Join Mathiasdm [0] (n=Mathias@vpnb026.ugent.be) 18.17.00 Nick krz|afk is now known as krz_ (n=chatzill@mail.jvl.by) 18.18.13 Quit PaulJam (".") 18.20.11 # krz_: hey, I need help with the wps editor 18.20.38 # I guess I compiled it (qmake && make in rbutil/checkwps) but I can't open it 18.20.41 # kugel: so, what have you already done? 18.21.02 Quit nplus (Remote closed the connection) 18.21.04 # either I'm opening the wrong file or i don't know 18.21.27 Join mf0102 [0] (n=michi@85-127-21-119.dynamic.xdsl-line.inode.at) 18.21.35 # running gui in wpseditor/gui/bin gives error about libproxy.so not found, even though it's in the folder 18.21.52 Join nplus [0] (n=nplus@141.25.globcom.net) 18.23.15 # kugel: try to make it from wpseditor/proxy 18.23.34 # The file is there 18.23.51 # ll .../bin shows gui and libproxy.so 18.23.58 # ll = ls -l 18.24.23 # may be copying to gui/bin will help? 18.24.42 # it's there!!! 18.25.16 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.25.28 Join superkaybee [0] (n=kurt@justman.NetDirect.CA) 18.25.34 # kugel: try going to gui/bin first. I always did it that way 18.26.20 # i did 18.27.16 # It works here 18.27.33 # gevaerts: have you succeded? 18.28.15 # krz_: so you're in bin/, and you try running it with ./gui? 18.28.22 # kugel: so you're in bin/, and you try running it with ./gui? 18.28.32 # www.pastebin.ca/1187519 18.28.50 Quit linuxstb (Read error: 110 (Connection timed out)) 18.29.42 Join Schmogel [0] (n=Miranda@p3EE21F80.dip0.t-ipconnect.de) 18.30.40 # * gevaerts rebuilds from scratch to make sure 18.30.41 # krz_, gevaerts: weird, isn't it? 18.31.35 # I did "qmake ; make" to build, have I forgotton something? 18.32.03 # * gevaerts is confused now 18.32.45 # hm 18.32.58 # * domonoky thinks this is strange... are the permissions correct for the lib ? 18.33.13 # I can reproduce the problem now 18.33.33 # may running ldconfig as root fixes it? 18.33.40 # no 18.34.09 # I had an empty path somewhere in LD_LIBRARY_PATH, which apparently means the same as '.' 18.34.19 # or perhaps the wrong qmake ? it may be qmake-qt4 .. 18.35.04 # Nothing to do with it. It's the shared library loading path 18.35.38 Join nutsy [0] (i=Teapot@78-86-147-247.zone2.bethere.co.uk) 18.35.45 # You can work around it by 'export LD_LIBRARY_PATH=.' 18.36.07 # But that's not a proper solution 18.36.12 # Hi im sure this has been asked a thousand and 1 times... But is there any plans to release rockbox for Ipod Classics? Or is the encrypted firmware simply too difficult to crack? 18.36.19 # gevaerts: this is temporarily, isn't it? 18.36.40 # nutsy: Check the New Ports forum. That contains all info about this topic. 18.37.07 # kugel: that's for the current shell and its subprocesses only 18.39.12 # krz_: Are you trying to copy the libproxy.so to /us/local/qt4/lib or something? This dir was in my LD_LIBRARY_PATH, but apparently didn't even exist (so copying probably failed) 18.39.20 # gevaerts: working now, thanks 18.39.41 Quit Nico_P ("http://www.mibbit.com ajax IRC Client") 18.39.50 # kugel: why would it copy it there? 18.39.56 # no the lib will be copied into the gui/bin dir... i dont know why it doesnt look there... 18.40.55 # gevaerts: I just asked 18.41.14 # * domonoky checks where Qt does look for libs, on linux.. 18.41.23 # So, krz_, now tell me how to enter .rockbox with "Open WPS" when it's hidden? 18.41.45 # kugel: right-click and enable hidden things 18.41.56 # rasher from what i can tell it seems some hackers are trying... But there is no real plans from the rockbox team to suport the classics? 18.41.59 # is that right? 18.42.35 Join MethoS [0] (n=clemens@host-091-097-240-003.ewe-ip-backbone.de) 18.42.39 # nutsy: no. Some people are thinking that this is easy. They are wrong 18.42.42 Quit _hc () 18.43.37 Part J-23 18.43.38 # i never said it was easy 18.43.53 # I knew ages ago that the encrypted firmware was going to be a problem 18.44.06 # I just came in to see if there was any progress thats all :) 18.44.34 # nutsy: I mean that some of the people on the forum are seriously underestimating this 18.44.37 # Its no real biggy if they manage it or not... I would like it but i can live with apples front end 18.44.50 # ah ok 18.45.18 # so Qt4 docs says. that libs have to be in the system specific dirs ( ie the LD_LIBRARY_PATH on linux) unless you specify full paths when loading.. 18.45.53 # krz_: Ok, why is the preview of the wps not fullscreen (as in 176x220 for a e200 wps). It's a (roughly) 100x100 square o 18.46.04 # so in the future we my want to include those libs in the resourcefile (built into the binary) and specify full paths to it... 18.46.19 # but that isnt important for this first commit.. 18.47.35 # domonoky: but it's important that it runs after compiling without having the user to modify a path for the first commit imho 18.47.36 # kugel: krz_ job for now is to get it ready for commiting... (gsoc ends in 2 days), so thats improvements for later.. 18.47.49 # kugel: i conserned on H10 5gb 18.47.59 # * gevaerts is trying to find a way to make it work 18.48.31 # krz_: Nice that you don't mention this anywhere 18.49.19 # krz_: Anyway, besides that, it seems to work nicely. Good job. 18.49.40 # TODO: use real fonts for the preview 18.49.41 # kugel: thnx 18.50.01 # but that requires parsing the theme.cfg... 18.50.44 # * kugel would argue against having a complete theme editor instead of a wps editor, like with preview of the main menu 18.50.49 # a way to solve the lib problem: prepend the "currentPath()" to the librarys name in QwpsDrawer.cpp when loading the lib. 18.51.06 Quit nutsy () 18.51.27 # so its: QLibrary lib( currentPath() + "/proxy"); 18.51.34 # kugel: you can help with this after commiting, or you can create a patch 18.52.23 # krz_: Yea. It wasn't meant as a request (rather a suggestion for later), don't get me wrong. 18.53.04 # kugel: i will be happy if it gets into svn at the end of the week, feel free to improve it later :-) 18.53.45 # so its important that at leats all changes to rockbox code are properly discussed here.. 18.53.52 # domonoky: currentPath() doesn't seem to compile 18.53.53 # s/leats/least/ 18.53.58 # domonoky: I'll be happy if it's gets into svn today ;) 18.54.10 Join stu8ball [0] (n=stuart@host86-159-168-5.range86-159.btcentralplus.com) 18.54.12 # oh, its QDir::currentPath() 18.55.06 # krz_: should manage the commiting on his own (with help for creating the branch), its part of his tasks to fullfill his gsoc project successfully.. 18.58.44 # domonoky: creating a branch? Will it not be in the normal source? 18.59.05 # kugel: a week before the release? 18.59.24 # ah, forgot about the freeze 18.59.34 # How do you build this with debug symbols? 19.01.18 # does anyone have the pictureflow demo working on a sansa? 19.02.11 # gevaerts: debug symbols in which part of it ? :-) 19.02.14 Join ompaul [0] (n=ompaul@gnewsense/friend/ompaul) 19.02.18 Join faemir [0] (n=faemir@88-106-209-242.dynamic.dsl.as9105.com) 19.02.21 # domonoky: gui, mainly 19.02.50 # * gevaerts gets segfaults 19.04.30 # gevaerts: change the CONFIG line in gui.pro to mention "debug" (but then you need a Qt build in debug mode) 19.06.14 # btw, won't debug_and_release work? 19.06.56 Quit stu8ball_ (Read error: 110 (Connection timed out)) 19.07.41 # i dont know what debug_and_release does, when it doesnt find debug libs of Qt, if you only have debug in the CONFIG line, it will surely error if there is no Qt Debug lib available.. 19.08.13 # How do you print a line ? 19.08.14 Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) 19.08.20 # domonoky: will "./proxy" work instead currentPath() on lunux? 19.08.22 # * gevaerts is a Qt-newbie 19.09.38 # krz_: apparently it does, but that doesn't solve this entirely 19.09.41 # krz_: QLibrary mentions absolute Paths... 19.09.51 # You want to be able to run this thing from anywhere 19.10.03 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 19.10.04 # otherwise it uses the normal system libray paths.. 19.10.22 # ah 19.10.33 # Which also means that currentPath() isn't the correct solution 19.10.46 # gevaerts: QDir()::currentPath() is always the adfs.kja 19.10.49 # ups 19.11.17 # * gevaerts doesn't entirely understand that 19.11.40 # * domonoky has keyboard problems, maybe batterys get empty.. :-) 19.12.21 # currentPath is always the absolute path to the application dir, on all systems.. 19.12.54 # so it should be the right solution.. 19.13.19 # * gevaerts tries a bit more 19.13.31 # btw, currentPath tells working directory or dir with executable? 19.13.46 Join _hc [0] (n=hanschri@209.131.113.150) 19.14.00 # How do I print a line to stdout with Qt ? 19.14.11 # gevaerts: to print something, you can use qDebug() << "text" << somevar; 19.14.26 # it seems that it takes working dir, not executable 19.14.50 # QString QDir::currentPath ()   [static] Returns the absolute path of the application's current directory. 19.15.17 # "current directory" == working directory I think 19.15.29 Join Lambdumb [0] (n=Lambda@12-202-140-90.client.mchsi.com) 19.15.50 # jup, and we want current dir or executable dir? 19.15.55 # Maybe QCoreApplication::applicationDirPath() ? 19.15.56 Quit ZincAlloy ("CGI:IRC (EOF)") 19.16.13 # lets check how we solve this in rbutil .-) 19.16.28 # That works :) 19.16.38 # krz_: so you need QLibrary lib(QCoreApplication::applicationDirPath() +"/proxy"); 19.16.51 # but 19.16.52 # QCoreApplication::instance()->applicationDirPath() is the thing we use in rbutil 19.17.06 # ok 19.17.07 Join elinenbe [0] (i=elinenbe@76.29.222.54) 19.17.12 # krz_: then remove the -lproxy from the LIBS line in gui/gui.pro 19.17.32 # (otherwise you don't actually use the path from the source) 19.17.44 # Then test if it still works in windows :) 19.18.45 # But there is still a bug in QWpsDrawer.cpp. It segfaults when it can't open the library instead of printing a clean error message 19.18.48 # works 19.18.49 # what's the status on 3.0? What is the ETA? 19.19.31 # That may not be too important though, as it should never happen 19.19.58 # elinenbe: a few weeks. No precise ETA 19.20.24 # gevaerts: thanks. 19.20.27 # krz_: jup, you should check the return value of lib.resolve(..), if its 0 loading failed... and you should quit with a error message.. 19.22.15 # krz_: problem is in src/utils.cpp:17. You don't have a window yet there I guess 19.22.35 # * gevaerts checks 19.22.38 # Indeed. win==0 19.22.42 # jup, just fuond out that too 19.22.50 # *found 19.23.31 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 19.23.45 *** Saving seen data "./dancer.seen" 19.24.57 Join Lear [0] (i=chatzill@rockbox/developer/lear) 19.25.35 Part superkaybee 19.25.52 # Lear: have you seen FS#9306 ? I was pointed to you 19.26.57 # Read it now. Sounds strange... 19.27.31 # * gevaerts agrees. 19.29.31 # What's the deal with the anti-aliasing patch? how come that hasn't been committed yet? It's oh, so nice. 19.29.38 # Nico_P: ping 19.31.35 Join toffe82_ [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 19.32.05 # elinenbe: agreed 19.33.11 Quit Lambdugh (Read error: 110 (Connection timed out)) 19.33.13 # elinenbe: I think the reason there's fear that the it could slow down rockbox, especially since anti-aliasing hans't a high priority on embedded devices (yet every dap producer introduces it) 19.34.48 Quit krz_ ("ChatZilla 0.9.83 [Firefox 1.5.0.12/2007050813]") 19.35.23 # * gevaerts finds "#if 0" in that patch... 19.35.46 # Surely that's not meant for commit? 19.36.11 Quit _hc () 19.37.02 # gevaerts: I haven't said it's ready for commit. I agreed to the fact that "it's oh, so nice" ;) 19.37.19 # and it works flawlessly. Though I think the converter can be optimzed 19.37.32 # kugel: the question (not yours) was "why is it not committed?" :) 19.38.15 # anyway, remove the #if 0, and commit please :) 19.39.33 # gevaerts: Well, the size of the file shouldn't be a problem at least... (I.e., the codec doesn't run out of malloc_buf space.) 19.40.07 # Lear: the weird thing is that this doesn't happen if you restart from a normal bookmark... 19.40.55 # kugel: has it been tested on monochrome, colour and greyscale players? 19.41.17 Join _hc [0] (n=hanschri@209.131.113.150) 19.41.37 # gevaerts: Well, I didn't. monochrome is probably unsupported 19.41.53 # greyscale shouild work 19.42.12 # gevaerts: if you have such a target, feel free to test! 19.42.33 # gevaerts: Yes, I can see a problem too. Looks like a buffering problem; different ways of starting a file can cause subtle timing differences. 19.42.37 Join dig1 [0] (n=dig@pool-70-22-98-106.balt.east.verizon.net) 19.42.47 # kugel: well, I think that before it can be applied (if we want to, that's still something different) it needs to be cleaned up, and then the tracker needs to have some reports about different players 19.43.04 # kugel: and I don't care about this... 19.44.33 # Lear: if it's timing, this will be fun... 19.44.34 # gevaerts: I expected that. Most committer don't care about this patch 19.44.50 # The fact that playback.c was changed in r17923 is an indication too. 19.45.33 # gevaerts: Yeah, like the one I found recently. At first I couldn't consistently reproduce it, which made it extra fun. :) 19.46.16 # gevaerts: So, involving Nico_P too is an idea... 19.46.43 Quit J-23 (Read error: 104 (Connection reset by peer)) 19.46.51 Quit XavierGr (Nick collision from services.) 19.46.58 # s/playback.c/buffering.c/... 19.47.01 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 19.47.06 # kugel: as you know the current plan seems to be to allow "riskier" patches just after the release. I'd say make sure it has been cleaned up by then, get some people to test it (I can do some basic testing on various targets), and then try to convince a committer 19.47.54 # kugel: can you still do non-antialiased fonts with it? 19.48.03 # clean up as in remove the #if 0 stuff, or is there mroe? 19.48.28 # gevaerts: yes of course, and the creator said, they're rendered faster than in svn 19.48.47 Quit toffe82 (Read error: 110 (Connection timed out)) 19.49.02 Join miepchen^schlaf [0] (n=miepchen@p54BF4468.dip.t-dialin.net) 19.50.09 # Then you could have a chance :) It looks like RAM usage doesn't go up too much either (If I look correctly, 1460 bytes for ipod video. That can probably be talked about) 19.50.22 # Nico_P: ping 19.51.09 Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) 19.52.14 # kugel: I'm a bit worried about what the mpegplayer thing means in practice. Are there likely to be problems with more plugins? 19.52.56 # pong 19.53.31 # but I'm cleaning my appartment before leaving it, so I don't have much time to offer 19.53.35 # Nico_P: have you seen FS#9306 yet? 19.54.14 # no, I hadn't 19.54.34 # Lear thinks you may be able to help 19.54.35 # gevaerts: ah right, I forgot about that one. The font doesn't work in the WVS 19.54.44 Part virtuoso015 19.56.10 # kugel: My guess is that that sort of issue really needs to be solved 19.56.18 # Nico_P: I'm testing the buffering patch 19.56.29 # I'll have a runtime test available tomorrow 19.57.14 # gevaerts: the current workaround is to use the sysfont in the wvs (the mpegplayer menu is fine= 19.57.16 # ) 19.57.41 # kugel: a workaround is fine for an optional patch, but not really for svn 19.58.43 # gevaerts: I know 19.59.18 Quit GodEater__ (Remote closed the connection) 19.59.35 # gevaerts: I'll try to fix it. I can't promise though. I don't know if mpegplayer or the patch is the problem 19.59.37 # * Llorean wonders what the heck a "wvs" is. 19.59.50 # * pixelma too 19.59.53 # and I didn't create the patch. Actually both, mpegplayer and the patch are a mess for me 19.59.53 # kugel: thanks 19.59.54 # Llorean: while viewing screen? 20.00.03 # while video screen :) 20.00.10 # There's hardly a "while video screen" 20.00.14 Quit saratoga ("CGI:IRC (EOF)") 20.00.16 # There's a video overlay. 20.00.20 # Or there's the video itself... 20.00.56 # but generally, I think there are much more important things concerning fonts than anti-aliasing 20.01.00 # I remember it being called that like that when the feature was committed 20.01.26 # pixelma: like? 20.01.28 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 20.01.34 Quit stripwax (Client Quit) 20.01.38 # kugel: multi-font? 20.01.38 # pixelma: Honestly, I think antialiasing improves very few fonts. It generally decreases readability on the players, for me. 20.02.12 # I'd also like to know how well the antialiasing hack works for complex unicode characters. 20.02.26 # Llorean: true, the better readability only sets in for fonts larger than 12 or something pixel 20.02.30 # yeah, that too. The 2 screenshot in the forums I've seen look really blurry 20.02.46 # My view is that if it turns out to be cheap (RAM and CPU wise), it doesn't remove the ability to use normal fonts, and someone else does the work, why not? 20.02.47 # kugel: No, I think it actually just makes those tend to look out of focus. 20.03.00 # Generally, the better readability seems to be a very case by case basis for me. 20.03.04 # gevaerts: I don't see why we should wait with the 1 font thing while waiting for another font thing 20.03.15 # kugel: In case they conflict. 20.03.20 # Multifont is a higher priority. 20.03.33 # kugel: the ability to use at least 2 different fonts for remote and main screen (or mulitfont in general) 20.03.43 # so, rockbox is stalling until multifont? 20.03.51 # yes :) 20.04.05 # of course... 20.04.06 # * gevaerts won't commit anything until multifont is ready 20.04.30 # kugel: Why does "maybe we should wait on antialiasing, a trivial feature that might conflict" mean "Rockbox is stalling"? 20.05.00 # but actually I wanted to "oh noe" at the anti-aliasing question again... :\ 20.05.07 # Neither multifont nor antialiasing are actually ready, so why even discuss this? 20.05.36 Join GodEater_ [0] (n=ge@rockbox/staff/GodEater) 20.05.38 # AAF shouldn't conflict with multifont. The fnt format isn't even really touched by AAF 20.06.28 Quit nuonguy ("This computer has gone to sleep") 20.06.31 # and it works well with the multifont patch on the tracker 20.07.11 # You mean the one that hasn't been committed because it's not done right? 20.07.36 # speaking of stalling, are we up for a release branch done this weekend? 20.07.52 # gevaerts: discuss to create motivation to get the it ready. I'm hardly motivated to make any of the patches ready, if I always here stuff like this 20.08.00 # Llorean: yes 20.08.13 # Bagder: I really wish the Playlist bug would get fixed, and recording would work, but I don't think theres' any showstoppers at the moment. 20.08.43 # kugel: So basically "I can't be bothered to try to fix the patches, if people are going to wait to make sure they work before committing them"? 20.08.58 # Llorean: I'm mainly thinking there's a push building up to commit new stuff, so it would be good to get a branch to "settle" and cleanup for 3.0 20.09.13 # Let's do it. We can still backport more important fixes if they happen before the release 20.09.19 # exactly 20.09.21 # Bagder: I see no problem at all with that. Recording at least is a minor cleanup, I think, because we can just disable it for the iPods if we need to. 20.09.31 # kugel: also, someone mentioned potential to get font caching, its RAM usage etc. more efficient - that would be more important to me 20.09.37 # And the playlist thing hardly has anyone complaining about it, so obviously it's not *that* major. 20.09.40 # Llorean: No, not bothered to make AAF patch ready, if you wait for multifont anyway (which I'm not able to fix, and noone else bothers too either) 20.10.08 # kugel: How much does AAF increase BIN and RAM usage, anyway? 20.10.41 # I haven't done any measures. geaverts said it adds ~1400 ram 20.10.56 # Llorean: which playlist bug are you talking about? 20.11.06 # but if the creator is right, and it also speeds up font rendering, I'd say it's definetely worth it 20.11.46 # pixelma: One associated with moving files and having the cursor end up in the wrong place 20.12.02 # kugel: Or we could take the font rendering speed increase, and drop the RAM waste... 20.12.17 # kugel: There's no rule that says we have to take both, especially if it's a pretty large RAM hit for a very, very trivial feature. 20.12.19 # rockbox-info.txt without AA : http://pastebin.ca/1187661 , with AA : http://pastebin.ca/1187662 20.12.37 # Llorean: Why do you think the RAM is "wasted" by the anti-aliased only? 20.13.30 # kugel: Feel free to demonstrate otherwise, then. 20.14.02 # Llorean: Why should I? You've made the assumption, and I want both 20.14.13 # Llorean: ok, I know that one (and commented on) 20.14.15 # kugel: And you have to justify the patch. 20.14.26 # kugel: If you want to justify it, show that antialiasing's added cost is minimal. 20.14.39 # * gevaerts would say first make it work properly 20.14.48 # gevaerts: That bit's obvious though. 20.15.49 # pixelma: Yeah, I don't consider it major, but it's one of the bugs that seems like it'd be in the direct sight of users since it's a feature that's core to the experience, in a way. 20.16.00 # pixelma: But if necessary, the fix for it can prompt a 3.0.1 or something. 20.16.11 # Llorean: I hope so. However the task has lots of discussion about creating fonts, and none at all about fixing an issue with the patch itself that was brought up early 20.16.27 # Llorean: Sadly, I can't proove anything(yet?). I didn't create the patch. I don't know which part is "speed up rendering" and which is "aaf" 20.16.50 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 20.17.05 # Llorean: yes, it's quite annoying 20.17.23 # pixelma: Can you repro the playlist problem at all? 20.17.33 # I couldn't 20.17.47 # pondlife: yep, see last comment 20.17.58 # Ah, on Flyspray? 20.18.00 # I find it sad, that there's so much prejudice about AAF. 20.18.15 # kugel: Prejudice? 20.18.22 # Are you aware of what the word actually means? 20.18.31 # I would like to see AAF done 20.18.33 # pondlife: http://www.rockbox.org/tracker/task/7967 20.18.42 # Llorean: yes I do 20.18.44 # but I'm not in a hurry and it needs to be done right 20.18.44 # kugel: Prejudice requires one not be aware of the facts. 20.18.51 # kugel: It's entirely a matter of opinion. Personally, I dislike ClearType, is that AAF? 20.19.05 # pondlife: it really seems to be related to shuffle 20.19.06 # kugel: I guess there is a lot of prejudice on the side of those who think it should go in without fixing it... 20.19.25 # pondlife: or a shuffled playlist 20.19.30 # pondlife: AAF is a cheap and dirty thing in the general category of cleartype (which honestly looks MUCH nicer) 20.19.31 # pondlife: pretty much, yes. But it's not like you're forced to use AA fonts, you can still happily use normal fonts 20.19.42 # kugel: We're forced to give up our RAM and binsize for it. 20.19.46 # I prefer the clear edges, no blurring. 20.20.21 # pondlife: what's really weird - is that not everything looks wrong (at least for me) 20.20.40 # kugel: Honestly, if you have no interest in attempting to improve the patch, just say so. 20.21.11 # Llorean: I have, but not if I know there's nothing gonna happen until multifont 20.21.48 # kugel: 1) I said I think it should take a back seat to multifont. You asserted it won't conflict. You can always show this. 20.22.13 # kugel: 2) If you fix it now, it'll still be fixed then. In fact, it'll get in sooner then, if multifont does delay it, because it won't have to be resynced and you can fix the objections now rather than waiting. 20.22.28 # How? How can I show it won't conflict with something not existing? 20.22.43 # Well, you're the one who said it won't. 20.22.52 # I assumed you at least had some convincing argument to back up that assertion. 20.22.55 # I said it *should* 20.22.59 # should not rather 20.23.10 # But you have no reasoning for this? 20.23.59 # My point, though, is that I don't understand why "people are hesitant about this patch" means "I won't work on it, until they're not" when working on it will *reduce* said hesitancy. 20.24.22 # I'm the only one who's said I think it should take a back seat to multifont, and even then, I haven't said it *must* 20.24.31 # * domonoky thinks we dont have to make this dependend on multifont, if it gets ready it should go in.. 20.24.48 # Llorean: I had my reasoning, and you read it. I can't have any other reasoning, since multifont doesn't exist 20.25.09 # domonoky: All I want to know is that it won't conflict with multifont, since I think if we have to decide between the two, multifont is higher on the list. 20.25.40 # What makes you think you can only have 1 of them? 20.25.50 # kugel: See the key word IF 20.25.57 # ah sorry 20.26.02 Join yoo [0] (n=ich@141.30.81.182) 20.26.08 # * domonoky thinks as the real multi.font patch doesnt exist/isnt ready, e can not know if there are conflicts.. 20.26.37 # domonoky: But we can look at what parts of the font system a working AAF changes and see if any of those seem likely to provide problems. 20.26.40 # gevaerts, domonoky: I can't see a problem with the wpseditor just going into trunk - there are almost no changes to existing code. 20.26.44 # the only real way to know is to let time tell, and fix the conflicts when we know them.. 20.26.52 # but you cannot know that until multifont exists, and it's not looking like it's going to live soonish, and that's why in fact aaf has to wait in your opinion 20.27.21 # can we give svn write access to only a sub-folder ? 20.27.33 Quit gevaerts (Nick collision from services.) 20.27.42 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 20.28.05 # domonoky: We just trust people to only commit in certain folders. If they don't, it's easy to both revert the commit, and revoke their commit rights... 20.28.13 # kugel: Look, frankly, quit complaining. I offered my own personal opinion. If I'm enough to keep you from working on it, then don't work on it. 20.28.58 # I think that 1) The problems need to be fixed, 2) We need to see if the size can be reduced significantly, and 3) Someone who has an idea what multifont will need to touch should see if there are any obvious likely conflicts. 20.29.12 # linuxstb: its just, because he has not earned his commit rights the normal way.. but i want him to do his as part of his project... 20.30.44 # domonoky: I'm not sure I understand your intentions. I would have expected someone else (you?) to commit the first code, and then commit patches for krz until which time he's offered svn write access - i.e. the normal procedure. Is there a different plan? 20.32.29 # * gevaerts would also prefer it that way 20.33.34 # i thought about a seperate branch/folder to which he has restricted access... because he should learn how to interact with the community, find the right people, knows the tools, and be forced to fix his svn problems with rockbox svn.. 20.33.41 Quit ender` (" "You have the right to remain silent. Anything you say will be misquoted, then used against you."") 20.34.26 # last week i gave him a list of things to do, or he wil fail his project. one of those things was, to get it into rockbox svn.. 20.34.32 # As I said, we can just restrict access "socially", rather than technically. 20.35.05 # domonoky: dropping that one requirement wouldn't be the end of the world IMHO 20.35.17 Join oofus [0] (n=chris@oofus.demon.co.uk) 20.35.29 # But doesn't "getting it into rockbox svn" just mean that _someone_ commits? 20.35.36 Join merbanan [0] (n=banan@83.233.242.76) 20.36.22 # The thing with this branch access is that eventually we will get into the situation that we don't want such a person to have commit access after all (or yet), and then you have to take it away. That's much harsher than not giving it in the first place 20.36.45 # And if he wants to continue working on it after SoC, I can't see a problem with giving him SVN rights quite soon - i.e. after the first commit, and maybe after a couple of patches. 20.36.53 # hm,jup, we could change the way it gets into rockbox svn... i only care, that it is in svn by the end of the week... 20.37.34 # and he should be much involved in this process of commiting, so he learns how this is done, 20.37.55 Join Thundercloud__ [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 20.38.12 # domonoky: the end of the week == tomorrow ? 20.38.41 # domonoky: He should also be in the process of communicating with the other devs and committers. I'd think that was a more important skill, but maybe I'm misunderstanding. 20.38.44 # his deadline is saturday midnight... so i have to last day to write his review.. 20.39.21 # yes, that was one of the intended things, be forced to talk to other rockbox devs to solve the svn thing.. 20.39.44 # i.e. the requirement boils down to him have a patch which is good enough to commit...? 20.40.04 # domonoky: Ah, you're also talking about his technical problems accessing the Rockbox SVN server? 20.40.24 # linuxstb: thats another intended thing... :-) 20.41.39 # How is the actual editor coming along? What functionality is there? 20.41.51 # * linuxstb should probably wait until krz returns, and ask him... 20.42.52 # i am not really satisfied.. at the moment its more a text editor with a animated wps preview.. but you should ask krz :-) 20.43.35 # but i think he has at least the basics there, so if he fullfills all my last requirements, i will let him pass.. :-) 20.43.55 # domonoky: Is the WPS preview realtime or via a "preview" or "update" button? 20.45.14 # last time i checked, there was a update button to reparse the wps. But the preview is animated and you can change things like shown artist etc live.. 20.46.16 # * gevaerts wouldn't want live updating on a text input. Most of the time there would be no valid wps... 20.46.27 # Does it use the core code to display the WPS, or has it been re-implemented? 20.46.39 # thats rockbox code.. 20.46.53 # he reused wps parser and display code.. which is nice.. 20.48.06 Quit pondlife (Read error: 60 (Operation timed out)) 20.49.42 Part dig1 20.50.43 # * gevaerts hopes that the wps editor patch doesn't conflict with multifont 20.50.55 # * gevaerts runs away and hides 20.51.05 # :-) 20.53.12 Quit Thundercloud_ (Read error: 110 (Connection timed out)) 20.59.58 Join ender` [0] (i=krneki@foo.eternallybored.org) 21.04.16 Join krz [0] (n=irc_by@turbo.sml.by) 21.04.31 Part J-23 21.06.43 # krz: so your svn problems are solved ? 21.06.54 # yes :) 21.06.58 # i hope 21.07.14 # for a long period of time, may be forever 21.07.18 # good... 21.08.17 # so now the question is, how to get your code into svn... 21.08.56 # we have a patch.. 21.09.41 # as others said earlier, we want you to go through the normal way of getting svn access.. so "someone" has to commit your patch :-) 21.09.53 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 21.10.16 # who will be this lucky man? :) 21.11.13 # * domonoky would really like it, if you could convince another rb dev (other then me), that the patch is good enough, so he commits it :-) 21.11.47 # hm, may be co-mentor? i've never asked him before.. :) 21.12.40 # why not... 21.13.11 # or some other devs here like gevaerts or linuxstb or others... 21.13.38 # so, any volunteer? 21.13.42 # :) 21.14.37 Join bluebrother [0] (n=dom@rockbox/staff/bluebrother) 21.15.22 Quit Pegasus_ (Read error: 104 (Connection reset by peer)) 21.15.39 # * bluebrother notices linuxstb did the BOM change he held back until 3.0 21.16.16 # if there is really no volunteer, i will do it shortly before your deadline. But you should really try to find one.. 21.17.47 # bluebrother, I think it was needed for a fix :) 21.18.07 # bertrik: noticed that. Should've dome that simply myself :) 21.18.16 # linuxstb: The main flaw I saw with the editor was that it only shows the preview in a box which apparently has the dimensions of a h10 screen 21.18.24 # gevaerts: could you be a volunteer? 21.18.26 # then that bug would've been fixed earlier. But anyway, doesn't matter anymore 21.19.08 # * bluebrother would like to see a all-targets-build of the editor first (even if it's not completely finished) 21.19.23 # krz: Why is this anyway? 21.20.09 # jup, a all target editor would be nice, but i want it in svn before his deadline saturday midnight... 21.20.32 # why that? Does the deadline require the code to be in svn? 21.21.07 # google doesnt require this, but i do.. :-) 21.21.28 # well, I'm not sure if this is a bit too rushy 21.22.16 Quit Thundercloud__ (Read error: 110 (Connection timed out)) 21.22.35 Join gaurdro [0] (n=Menschen@unaffiliated/gaurdro) 21.23.14 # all changes needed on rockbox code, should be properly discussed here, but the other code doesnt really hurt.. its in a seperate dir like rbutilqt 21.23.47 *** Saving seen data "./dancer.seen" 21.24.14 # and i really want it in svn till end of gsoc, or else it will just sit in the tracker forever... 21.24.21 # * bluebrother is against doing things in a rush -- we already have those problems all day at work ... 21.24.43 # well, I don't think it would rot in the tracker ... 21.24.48 # and its not like i said this to him earlier.. he knows this for quite some time.. 21.25.13 # so its one of the requirements i have, to let him pass... 21.25.34 # your requirements to have him pass is you doing work? ;-) 21.26.04 Quit Horscht ("electromagnetic radiation from satellite debris") 21.26.06 # no, i want him to find someone else to commit it, so it gets another review and maybe fixes.. 21.26.32 Quit Schmogel (Read error: 104 (Connection reset by peer)) 21.26.45 # only if all fails, i will commit myself... 21.27.18 # well, from now until saturday isn't quite long, especially if one wants to review the complete code 21.27.43 # and I'm really against some namings -- like "proxy". 21.28.08 # so, what name would be better? 21.28.24 # well, maybe something like "libwps"? 21.28.44 # proxy could be anything. We have a proxy setting in rbutil for example, which is completely different 21.29.30 # ok 21.29.36 # same for "gui". gui what? Could be anything too 21.30.05 # any proposes? 21.30.24 # app 21.30.32 # kugel: as bad as gui 21.30.46 # well, why not call it "wpseditor"? At least that's what it is. 21.30.52 # oh I just thought because of the apps dir 21.31.08 # * domonoky remembers some plans about rbutil restructuring in: core, cli and gui :-) 21.31.39 # also, there were quite some filename casing issues in the past. I think it would be less error-prone if all filenames would be renamed to lowercase 21.31.54 # so proxy should be changed but gui ? 21.32.11 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 21.32.47 # krz: Would be nice if you answer my question 21.33.05 Part fragilematter 21.33.07 # well, how exactly should the directory layout look like anyway? As far as I understood "gui" and "proxy" would go below rbutil 21.33.13 # kugel: what question? 21.33.29 # * bluebrother didn't notice a question of kugel too 21.33.41 # kugel> krz: Why is this anyway? 21.34.09 # referring to the flaw I told linuxstb 21.34.20 # kugel: i can't answer to you right now 21.35.16 # Hm, when I log out of flyspray nowdays, I get a blank page... Refresh doesn't help. 21.35.30 # Lear: FS is kinda broken these days :/ 21.38.28 Nick oofus is now known as oofus[away] (n=chris@oofus.demon.co.uk) 21.38.30 # krz: ?? Why can't you answer? It's your software? 21.40.01 # kugel: you mean why it only shows the dimensions of the only target it supports at moment ? 21.40.34 # yes 21.41.21 # it's parsing for e200, else checkwps fail, isn't it? So why restrict the preview size 21.41.23 Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) 21.41.33 # * domonoky thinks this is because he uses rockbox drawing code, so it draws the size it is compiled for... but i am not sure 21.41.33 Quit linuxstb (Nick collision from services.) 21.41.39 Nick linuxstb_ is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) 21.41.46 # kugel: please ask tomorrow in the afternon when i will have access to my latest code. cos i can't even guess now 21.42.34 # Why is the wpseditor under rbutil/ ? It's not part of rbutil... 21.42.54 # linuxstb: it could be a part potentially 21.43.00 # maybe rename the rbutil folder? It also holds ipodpatcher and sansapatcher 21.43.15 # It holds ipodpatcher and sansapatcher because they're part of rbutil... 21.43.18 # and checkwps 21.43.21 # oops 21.44.03 # that's in tools 21.45.34 # * domonoky checks the wps editor code. The wps size is really the target lcd size (which is at moment the h10 i think)... 21.46.15 # I was wondering how the wpseditor dealt with that problem (LCD size being fixed at compile-time). So I'm guessing it doesn't (yet) ? 21.46.25 # we currently have tools and utils. hmm. 21.48.31 # linuxstb: I guess this is meant to be handled the same way as in the checkwps gui krz did earlier. That shouldn't be too much work, it just needs to be done... 21.48.45 # linuxstb: i haven't yet done, but it can load libraries on runtime potentially. if you remember gui for checkwps - you'll understand 21.48.56 # gevaerts: jup 21.51.52 # krz: I could do the commit for you, but then we need to find a few hours tomorrow when we can both work on this (I'd like to review the "real" GUI part a bit too if I'm the one who commits, and it's easier if you're online at the same time) 21.52.17 Quit Horscht ("electromagnetic radiation from satellite debris") 21.52.52 # linuxstb: i think that should be solved with the different libs... there will be surely some problems, but it should work.. :-) 21.53.03 # krz: I'll basically be available from 17:00 UTC to . I can probably find some time earlier to already look at things, but not to really work on it 21.53.41 # gevaerts: i'll be from 14 UTC 21.54.00 # reacocard: hi! sorry about not answering your mail yet, have been so busy at work.. :/ but trying to answer soon 21.54.17 # reacocard: and update the wiki more 21.54.31 # gevaerts: btw, there are no latest patch in a tracker yet. it will be tomorrow 21.55.23 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 21.55.37 # reacocard: in fact, here are some answers: 1) it only affects the in-memory copy 21.55.49 Join massiveH [0] (n=massiveH@pool-72-76-34-19.nwrknj.fios.verizon.net) 21.55.55 # reacocard: 2) it was just a type 21.56.02 # *typo 21.56.12 # krz: I agree with the requests to rename "gui" and "proxy" by the way. Proxy is less critical as those are basically internal libraries that nobody will see, but "gui" should indeed be something like "wpseditor" 21.56.26 Quit yoo ("Verlassend") 21.57.01 # reacocard: 3) deleted is just for efficiency purposes, it would be way too overkill to rebuild the entire db to vanish master index data. But it would be possible to re-use that old data in master index 21.57.14 # Maybe the proxy libraries should be placed in bin/lib/ so you don't have to see them if you don't want to 21.57.44 # reacocard: RESURRECTED is mostly for informative purposes (not used yet). But it can be used to check which files have been moved/modified and the statistical data has been resurrected 21.58.32 # gevaerts: oki :) 21.58.34 # Slasheri: alright, thanks for the info. 21.58.45 # reacocard: 4) serial is an always incrementing integer. When a song statistics are begin updated, serial is always incremented by one and the song's lastplayed is set to the current serial 21.58.55 # ah 21.59.07 # krz: if you have time until about 20:00 UTC we would have about three full hours to really work on this. I guess that's probably enough 22.00.02 # gevaerts: hope too 22.00.11 # reacocard: and the most important, db is endianless, as long as the endian won't change inside the db 22.00.22 Join webguest76 [0] (n=4b44a542@gateway/web/cgi-irc/labb.contactor.se/x-85d2a8ff831f2a0e) 22.00.25 Quit webguest76 (Client Quit) 22.00.31 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 22.00.34 # so the code operating with db should be able to handle both little endian and big endian 22.00.47 # Slasheri: well as Im reading straight from the disk files I have to wrroy about the endianness 22.00.52 # hm.. a argument against placing libs into bin/libs is: just build them into the resource file which is embedded in the binary.. :-) 22.00.55 # Im nto using the existing code 22.01.06 # domonoky: does that work for shared libraries? 22.01.10 # Slasheri: Endianless? Iiuc the db can handle both endianesses, but the native endianess of the respective target should be faster 22.01.11 # reacocard: yes you need to worry about that if reading the db from player.. 22.01.22 # iriver's have big endian, while ipods are little endian 22.01.26 Quit ompaul (Client Quit) 22.01.37 # amiconn: yes, that is what i meant 22.01.49 # it should, the resourcefile is for qt like another filesystem.. if not, you could copy them to temp while running.. 22.01.51 # db uses always native endian but can handle both 22.01.53 # domonoky: well, in that case you won't be able to distribute only the needed libs. In fact, for minimizing download size it might be useful to offer the libs separately for download 22.02.01 # Slasheri: Btw, will we see a fix for fs #9093? 22.02.09 # amiconn: i will check 22.02.26 # but the editor shouldn't crash when no lib is found. No idea if it still does but it did the last time I tried 22.02.30 # Slasheri: alright, are irivers the only big endian target or are some of the others big? all the portalplayer based ones are little I know, but the others? 22.02.42 # domonoky: well, I would suggest to look into that later. The libs/ move should be trivial (one copy in a makefile and one path in the source) 22.02.45 # iirc, archoses _might_ be big endian also 22.02.49 # reacocard: All coldfire and SH1 targets are big endian 22.02.54 # bluebrother: it still does, but at least it's known why 22.03.00 # thanks amiconn 22.03.08 # jup, the lib thing can come later. 22.03.14 # All current arm targets are little endian 22.03.23 # * gevaerts would like to see that fixed 22.03.34 # well, we could even think about the editor download its needed binaries itself. Of course that's something for later 22.03.48 # * bluebrother is with gevaerts here 22.04.05 # * krz waits till tomorrow 22.04.44 # amiconn: ah, that old bug.. 22.04.56 # yep :/ 22.05.23 # amiconn: sorry, really trying to fix that as the next thing when having time to code something 22.06.00 # bluebrother: the proxy libs are 45k each compressed. That means about 1.5MB to download all 22.06.29 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 22.06.32 Quit shotofadds (Read error: 104 (Connection reset by peer)) 22.06.46 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 22.06.48 Quit shotofadds (Read error: 104 (Connection reset by peer)) 22.06.53 # Slasheri: Im curious though why you dont just update track info in-place if, for example I change the year tag (via an external program). It doesnt change the size or number of entries at all, so shouldnt it be more efficient to just do it in-place? or was this just done for code simplicity? 22.07.01 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 22.07.03 Quit shotofadds (Read error: 104 (Connection reset by peer)) 22.07.28 # Actually, 7zip compresses 11 libs down to 80k 22.08.02 # unfortunately you can't upx libraries ... 22.08.03 # reacocard: that is just for simplicity (every tag changing is handled similarly) 22.08.11 # * krz wonders if debug info takes much 22.08.19 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 22.08.33 # it does, at least for binaries. But it also depends on the debug infos 22.08.54 # Slasheri: ok, so in my computer-side updater it would be reasonable to just do it in-place right? 22.09.12 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 22.09.13 # so, it can be even less 22.09.14 # reacocard: if mtime has been changed, a new entry is always created and data resurrected from old entry if some conditions apply 22.09.20 # reacocard: yes 22.09.26 # ok 22.09.31 # krz: this was without debug info 22.10.24 # ah 22.10.43 # Slasheri: would it also be fair to, if I found an entry flagged as resurrected and a matching entry flagged as deleted, to remove the deleted entry and the resurrected flag? 22.11.17 # reacocard: probably yes, at least i have yet no idea how to use the resurrected flag 22.11.25 # heh 22.11.30 # ok 22.12.43 # at least it would be safe to remove the deleted entry in that case completely 22.13.43 # i have been thinking that in other cases, an automatically updated "delete log" simlar to the changelog could be created on disk 22.13.55 # so statistical data from deleted songs would also remain forever 22.15.07 # interesting idea 22.15.50 # but deleted entries without a corresponding resurrected I should leave in place to allow for future resurrection right? 22.16.27 Nick topher|away is now known as topher (n=topher@epiar/founder/topher) 22.16.42 # not sure about that.. probably you shouldn't leave them in-place because tagcache engine destroys tag information from deleted songs in next update anyway 22.16.55 Join Thundercloud_ [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 22.16.59 Join fml [0] (n=4fd3df23@gateway/web/cgi-irc/labb.contactor.se/x-764c059a91811bc4) 22.17.01 # right but it doesnt reference it from the DB anymore so thats irrelevant 22.17.01 # and after that information is lost, no resurrection is possible 22.17.19 # really? but its stores the crc32 in the old spot 22.17.31 # so you could take the new tag info, crc32 it and match it up 22.17.32 # ah! indeed.. forget about that 22.17.44 # you are correct.. hmm 22.18.25 # im pretty sure I saw code in tagcache.c that does exactly that 22.18.35 # He-he, linuxstb made what I proposed a couple of days ago (BOM + BOM_SIZE). But I didn't even assume that this would fix a problem! Which proves again: beauty is not only beautiful but also rational! 22.19.27 Quit jfc (Read error: 104 (Connection reset by peer)) 22.19.34 # fml: and only because I wanted to wait until 3.0 is ready :) 22.20.30 # reacocard: ah, the FLAG_RESURRECTED was there to prevent processing the entry again 22.21.14 # Slasheri: ah, an "I already resurrected this" flag. so it shoudl stay in place until all matching deleted entries are removed. 22.22.33 # indeed 22.26.04 --> "delete quote dicks" received from PAKIRAQI (n=Tiki@pool-96-229-232-141.lsanca.fios.verizon.net) 22.26.25 # alright, ive condensed most of what we just talked about into the wiki page 22.27.16 # thanks for all the info, it'll e useful :D 22.27.19 # be* 22.28.24 Quit krz (" ?") 22.28.39 Quit Thundercloud (Read error: 110 (Connection timed out)) 22.28.53 # reacocard: great :) 22.29.19 Quit _hc () 22.32.59 Join ^eRicSOn_Full^ [0] (n=ericson@124.104.71.170) 22.33.04 # hm, python doesnt have a crc32 module..... 22.33.25 Quit ^eRicSOn_Full^ (Client Quit) 22.35.44 Quit Thundercloud_ (Read error: 104 (Connection reset by peer)) 22.36.30 # reacocard: the higher 16 bits of the flag contains an index of the entry in the master dircache index. That should be the entry id in master DB index 22.36.48 # it has nothing to do with dircache, just a way to prevent extra lookups to fetch that index id 22.37.06 # reacocard: But a couple of crc32 functions (binascii and zlib modules)... 22.37.15 Quit merbanan (Remote closed the connection) 22.37.16 # but once you're reading that entry dont you already know that index? or is this a different index? 22.37.36 # Lear: yeah I foudn one I can use in zlib. its not exposed in haslib as Id expect though. 22.37.42 # er, hashlib 22.38.03 # reacocard: it's more complicated.. i don't remember the excact cause right now but we don't know it 22.38.10 # hrm 22.38.10 Quit fml ("CGI:IRC (EOF)") 22.38.21 Part Bensawsome ("The awsome is gone :(") 22.38.40 # btu its onyl set when dircache is enabled right? and thus only on the in-ram copy? 22.38.51 # reacocard: or we know it but that information "gets lost" when building a lookup for data retrieval 22.39.00 # indeed 22.39.01 # reacocard: CRC isn't suitable for hashing, so no surprise there, really. (According to the binascii module.) :) 22.39.17 # reacocard: i will check the exact use of that soon 22.39.38 # Lear: well, it is a HASH, so id expect it to be in there with a warning as to its ineffectiveness 22.39.42 # Slasheri: thanks 22.40.32 Join ZincAlloy [0] (n=d9eee040@gateway/web/cgi-irc/labb.contactor.se/x-be474d2338974c02) 22.42.57 Nick topher is now known as topher|away (n=topher@epiar/founder/topher) 22.42.57 Quit Lear ("ChatZilla 0.9.83 [Firefox 3.0.1/2008070208]") 22.43.49 Join dandin1 [0] (n=anon2155@GreenOnions.broker.freenet6.net) 22.45.37 # Slasheri: Ah hey 22.46.03 # kugel: hi 22.46.22 # any idea about the sort tags patch 22.46.34 # reacocard: yep, get_next() needs that index id because there is no other way to get it when dircache is used 22.46.40 # kugel: it looks good 22.46.41 # 1 thing I didn't do is to bump the database version, but can that cause this? 22.46.47 # kugel: but no idea why it causes issues 22.46.53 # Slasheri: ok, thanks 22.47.07 # kugel: you must bump the version, or rebuild the db 22.47.21 # Slasheri: I wonder if parsing the files created with reacocard/my own script reveals something. 22.47.21 # if you have completely rebuild the db, it shouldn't be the issue 22.47.30 # I did rebuild 22.47.40 # then it shouldn't cause the problem 22.47.41 # deleted tcc files 22.47.45 # tcd* 22.47.56 # what patch is this? im curious 22.48.10 # Slasheri: I've tried turning load to ram off, it didn't help 22.48.17 # hmm, weird.. 22.48.31 # kugel: it would be great to find the cause 22.48.37 # but when I tried on the sim it was weird. I couldn't reproduce it there, but it also didn't show the album art 22.49.14 # reacocard: http://www.rockbox.org/tracker/task/7287 22.49.21 # v6 is acting weird 22.50.05 # oh interesting, I didnt even know about those tags. will have to look into this for Exaile 22.50.45 # reacocard: those tags are quite useful imo 22.50.52 # yeah they would be 22.51.07 # Im surprised noone has brought the lack of this to my attention yet 22.51.17 Nick topher|away is now known as topher (n=topher@epiar/founder/topher) 22.51.25 # Slasheri: sadly, my target is in use (running a bettery bench for Nico_P). I can't work on it right now 22.52.08 Nick oofus[away] is now known as oofus (n=chris@oofus.demon.co.uk) 22.52.17 # hmm.. just found a little bug in tagcache that can cause some problems :) easy to fix 22.53.18 # reacocard: If possible, can you try a build with this patch, build the database? After playing a bit around with the database browser and music playback, the database should be corrupt 22.53.33 # Slasheri: Yes? Where? 22.54.19 # reacocard: If you do so, please save the initial database files, and those after corruption, and then compare both 22.54.33 # Else I'll get my hands on it on the weekend 22.54.37 # kugel: I dont have access to my target right now either.... shipped it off to college already so Im stuck on sims for now 22.54.45 # ahh too bad 22.55.15 # sunday night is the earilest Ill have access to it 22.55.19 # Slasheri: Any idea why it doesn't corrupt on the sim? And why it doesn't show album art (I guess it's related)? 22.56.13 # kugel: really no idea :/ 22.57.30 # kugel: below the comment "Don't touch the dircache flag". That might destroy the entry index id from ram copy 22.57.40 # will commit the fix tomorrow. after having tested it 22.59.03 # Slasheri: Hopefully this is it 22.59.33 # kugel: probably it wont help with your issue but could fix some tagcache weirdness 22.59.55 # :( 23.00.08 # well, of course it _might_ also fix your problem 23.00.17 # and that would be awesome if it does! 23.00.46 # so your problem was missing entries iirc? 23.01.16 Quit Mathiasdm ("Invisible Internet Project: http://www.i2p2.de") 23.01.20 Quit dandin1 (Read error: 104 (Connection reset by peer)) 23.01.22 # well, it can't fix that unless you are using only the db in ram 23.02.26 # Slasheri: that was one problem 23.02.56 # ah, and the corruption.. 23.03.11 # are you sure your FS/HDD isn't faulty? 23.03.22 # tagcache fails very easily with a bad hdd 23.03.38 # because it uses disk so intensively 23.03.40 # The database is fine without the patch 23.03.45 # interesting 23.03.55 # oh.. just a moment! 23.04.01 # now i see the issue 23.04.56 # Slasheri: I've described the problems starting here: http://www.rockbox.org/irc/log-20080825#17:08:48 23.05.01 # kugel: you have added new string tags but forgot to update endian correction tables 23.05.04 # that is the problem 23.05.28 # ah 23.05.29 # (see the very beginning of tagcache.c) 23.05.32 # Yea, that's possible 23.05.39 # that will almost certainly fix the problem 23.06.11 # you need to add correct number of "l"'s to the table 23.06.59 # static const char *index_entry_ec ? 23.07.03 # yep 23.07.09 # hm 23.07.29 # that should contain TAG_COUNT +1 times the "l" 23.07.34 # couldn't that be made easier? so that one doesn't have to edit it there? 23.07.56 Quit bertrik ("Leaving") 23.08.01 # hmm.. you haven't incresed the TAG_COUNT either? 23.08.19 # just wondering how it did work at all 23.08.38 # hm 23.08.45 # probably the define could be moved closer to the TAG_COUNT define 23.09.16 # Well, I wasn't very much into tagcache (as I already mentioned). I thought/hoped the rest would be done automatically 23.09.36 # kugel: you need to update TAG_COUNT (in tagcahce.h) and that endian table 23.11.11 # couldn't tag_count be generated automatically? 23.11.25 # BTW: haha I did actually bump the db version 23.11.46 # it could, but probably it's simpler to do that way 23.12.16 # there's this enum tag_type, why not just have TAG_COUNT after tag_mtime? 23.12.18 # one updating tagcache code should know something about the internals in any way :) 23.12.35 # * reacocard notes that lack of docs/comments was one reason it took him so long to figure out how to parse the tagcache :) 23.12.58 # kugel: well, that is a good idea :) 23.13.08 # Slasheri: :) 23.13.20 # rasher: Translating 254 strings from English to Portugies could take approxiamly how long (if you know the language)? 23.14.11 # Zambezi: no idea (and someone's already working on the portuguese translation - check the tracker) 23.14.26 # Slasheri: why all the 1 in the endian correction? 23.14.39 # longs I think 23.15.09 # ah yea, it's l, not 1 23.15.16 # stupid font 23.15.22 # heh 23.15.24 # rasher: According to you homepage, last update is two years old. 23.15.48 # idk what font my gvim is using but it makes 1 and l look very different 23.16.16 # Zambezi: http://www.rockbox.org/tracker/task/9238 23.16.45 # Slasheri: How about using snprintf(index_entry_ec, "l", TAG_COUNT+1); instead of *index_entry_ec = "lllllll[...]"; ? 23.17.24 # rasher: Good it's in progress. I keep my eyes open for other needed people. 23.17.25 # if that works 23.17.27 # you could do that with memset too ... 23.17.54 # anything is better than this declaration imho, since it's dependant on something 23.17.58 # kugel: well, what if you added a field that wasnt a long in the future? 23.18.30 # every field is a long, even rating, so I doubt it'd happen 23.18.36 # * bluebrother wonders if *index_entry_ec is static 23.18.47 # s/static/const/ 23.18.51 # really, I think that the difficulty in changing the format isnt bad because changing the format is disruptive to users, and you should therefore think carefully before altering it 23.18.55 # static const char *index_entry_ec 23.19.10 Quit massiveH ("Leaving") 23.19.23 # bluebrother: both even ;) 23.20.16 # well, then your snprintf will create it in RAM, while it being const puts it into ROM. 23.20.31 # anyway, declaring it like static const char *index_entry_ec[TAG_COUNT+1], and copy something in later should be fine 23.20.38 # oh 23.20.41 # doesn't make much of a difference for most targets but if you (can) flash your player (like h100) :) 23.21.21 # or, to be more exact: const indicates it to be unmodifiable, which usually will put the string into ROM. 23.21.56 # bluebrother: and you can't alter data in rom using a pointer? 23.22.58 # kugel: well, it could be possible to preallocate and calculate the index_entry_ec during bootup 23.23.18 # but no need to add too much complexity for these simple thing.. 23.23.26 # programmer really has to understand doing these 23.23.35 # Slasheri: Well, as of now, it's complex to add tags 23.23.48 # no it's not 23.23.51 *** Saving seen data "./dancer.seen" 23.23.55 # once you know the internals.. 23.24.00 # more comments would be ok 23.24.10 # yea, indeed 23.24.12 # more comments are -always- a good idea 23.24.18 # kugel: well, ROM means Read Only ... :D 23.24.26 # until you have more comments than code anyway :D 23.25.01 # every code is complex if you don't know it. Except hello world maybe :) 23.25.06 # kugel: you must have a basic understanding of a piece of code before doing something with it 23.25.27 # no idea trying to automate everything 23.25.49 # Slasheri: I have now! Also, I hoped someone would help me with it, but apparently noone came to that idea 23.27.01 # Slasheri: I've even searched you for help, but you're unavailable at (many) times 23.28.25 # And understanding tagcache really ain't easy 23.30.57 # i dont doubt that.. tagcache is a very complex piece of code after all 23.31.45 Quit jgarvey ("Leaving") 23.32.17 # Slasheri: what kind of docs are there for it? 23.32.42 # the comments and http://www.rockbox.org/twiki/bin/view/Main/TagcacheDBFormat , so far as I know 23.35.59 Join thegeek_ [0] (n=nnscript@s080a.studby.ntnu.no) 23.36.55 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 23.40.54 # reacocard: haha 23.41.16 # Slasheri: I'll add a comment on how to add tags in my patch 23.42.32 Join gromit` [0] (n=gromit@ALagny-154-1-52-37.w81-249.abo.wanadoo.fr) 23.43.41 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 23.45.18 Quit faemir ("Leaving") 23.46.46 # gevaerts tried usb storage again tonight but although it got further than last time, it is still very slow and still can't copy the .rockbox folder 23.52.56 # Slasheri: I can't test on the target, but the sim shows the album art again, which is a good sign 23.53.58 Quit thegeek (Read error: 110 (Connection timed out))