00:00:24 | reacocard | 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 | kugel | hmm let me see |
00:00:54 | rasher | I still wish someone (Slasheri?) would pick up FS #7984 |
00:01:18 | reacocard | 3 and 4 shoudl map uniquely onto indicies in the main index |
00:01:53 | kugel | reacocard: wait, my parser is acting weird atm |
00:02:00 | reacocard | 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 | amiconn | reacocard: The fat32 specs are on the datasheet page. No need to repeat information... |
00:03:12 | reacocard | amiconn: ah thanks, Ill just link to that then |
00:03:45 | * | reacocard hasnt explored all of the wiki yet :) |
00:04:01 | kugel | reacocard: my parser fails to read the bytes on that 2 files |
00:04:16 | reacocard | kugel: wierd, mine handles them fine |
00:04:26 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
00:05:16 | Casainho | 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 | reacocard | heh |
00:06:06 | reacocard | I guess I better upload the mtime-enabled version of my parser too |
00:06:32 | amiconn | 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 | reacocard | ew |
00:06:54 | reacocard | 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 | amiconn | Existing files will increment the mtime by a fixed amount (1h 15min) when writing |
00:07:26 | reacocard | well, maybe not, since I can just use the real timestamp right? |
00:07:30 | reacocard | ugh |
00:07:55 | * | reacocard will think about that later |
00:08:15 | kugel | 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 | reacocard | kugel: I use the exact same parser for each |
00:08:32 | amiconn | 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 | kugel | reacocard: so i do |
00:09:17 | reacocard | kugel: perhaps you should look at my code and see what you're doing differently? |
00:09:25 | amiconn | 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 | kugel | reacocard: a) i can't read python so well b) my parser works different to yours, from what I've read |
00:09:51 | amiconn | What I'm talking about are files written/updated *by rockbox itself* |
00:10:10 | reacocard | amiconn: ok |
00:10:11 | kugel | But I parse every database_[0-9]+.tcd exactly the same |
00:10:33 | reacocard | kugel: well, im no great shakes at ruby but Ill give reading yours a stab |
00:10:42 | reacocard | where can I find it? |
00:10:48 | amiconn | 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 | kugel | http://pastebin.ca/1186826 |
00:11:58 | Llorean | 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 | kugel | line 55 and 56 are causing problems, but only on _3 and _4 |
00:12:51 | amiconn | Llorean: How would that be better? You cannot track the time the device was swicthed off |
00:12:58 | saratoga | its impressive how much smaller 7zip builds are then zips |
00:13:20 | kugel | reacocard: you'll need ruby 1.9 in case you want to run it |
00:13:24 | gevaerts | amiconn: it would at least keep all rockbox generated timestamps in the right order |
00:13:29 | reacocard | kk |
00:15:01 | amiconn | 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 | amiconn | You cannot have both without an rtc |
00:16:17 | gevaerts | 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 | gevaerts | If you care about exact times, use a player with an RTC I guess |
00:17:21 | amiconn | 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 | reacocard | kugel: so what's the invocation to run it? |
00:17:47 | | Quit DerDome ("Leaving.") |
00:18:05 | amiconn | If it has to go back when installing a new build, the step size was too large -> decrease |
00:18:11 | kugel | reacocard: have the database files in a "db_files/" subdir, then just do"ruby rb_db.rb" |
00:18:27 | amiconn | Next time there's a better chance that it doesn't have to go back |
00:18:32 | reacocard | kugel: kk |
00:18:42 | gevaerts | Except if you now and then install an older build |
00:18:50 | | Quit Zom ("leaving") |
00:18:51 | amiconn | Likewise, if it has to advance a lot with a new build, step size was too small |
00:18:54 | kugel | of course you can run it in the same dir, just alter the PathToDBFiles variable |
00:19:01 | reacocard | ah thanks |
00:19:26 | gevaerts | Or learn a lesson from DOS. Ask the current time at boot :) |
00:19:43 | amiconn | hahaha. That would be a major annoyance... |
00:19:52 | | Quit [CBR]Unspoken|w (Connection timed out) |
00:20:11 | gevaerts | You could do that by adding the set time/date screen to the possible startup screens |
00:20:32 | amiconn | The time/date screen doesn't exist on non-rtc targets |
00:20:35 | rasher | Not such an insane idea |
00:20:55 | amiconn | And I'd rather not introduce it |
00:20:56 | rasher | 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 | amiconn | It would require enabling a lot of other code that's currently disabled for non-rtc |
00:21:29 | rasher | gevaerts: any with digital input/output? |
00:21:38 | amiconn | rasher: yes |
00:21:42 | kugel | agrees with gevaerts |
00:21:49 | rasher | amiconn: Optical, then! |
00:21:59 | rasher | (which is in fact what I meant) |
00:22:00 | amiconn | Why does it need to be optical? |
00:22:14 | amiconn | Converting optical <-> coax is rather simple |
00:22:17 | reacocard | kugel: so, funny story. your parser read those entries perfectly on my system |
00:22:22 | gevaerts | rasher: mod it? |
00:22:32 | saratoga | 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 | Llorean | amiconn: And there's how many that aren't hwcodec though? |
00:22:37 | rasher | amiconn: Just because I'm aiming at telling that "h1x0 users might want it" |
00:22:41 | kugel | reacocard: Have you changed anything? I gave you the version which fails |
00:22:55 | reacocard | kugel: nope, not a single character |
00:23:05 | kugel | reacocard: your system is? |
00:23:18 | amiconn | Llorean: None afaik, but that wasn't included in the original question |
00:23:33 | reacocard | ubuntu 8.04, database is from a sansa e200 sim with 5 mp3s |
00:23:44 | * | kugel slaps himself |
00:23:54 | reacocard | ? |
00:23:55 | kugel | I got it, nevermind ;) |
00:23:58 | reacocard | lol |
00:24:18 | kugel | 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 | reacocard | ah yeah that would do it |
00:24:41 | * | reacocard double-checks to make sure he's using binary mode |
00:24:49 | Nico_P | "* 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 | amiconn | saratoga: I'm quite sure that you don't need thread_exit() |
00:25:05 | reacocard | yeah mine already uses it anyways |
00:25:05 | kugel | reacocard: On linux, there's no difference between binary mode and non-binary mode |
00:25:11 | saratoga | 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 | reacocard | kugel: im aware but I like my code cross-platform |
00:25:20 | RoCkEr | is rockbox available for classic yet? |
00:25:25 | kugel | on windows, you need to open the files in binary mode |
00:25:31 | reacocard | yep |
00:25:36 | kugel | I don't know if python has such a thing |
00:25:38 | Bagder | RoCkEr: no, and don't hold your breath for it |
00:25:39 | reacocard | in my case "rb+" |
00:25:44 | reacocard | the b is for binary |
00:25:50 | kugel | yea, same for ruby |
00:25:51 | gevaerts | reacocard: rockbox plus? |
00:25:58 | RoCkEr | k, what about linux? |
00:25:59 | reacocard | r for read, + is some kinda appendy thingy |
00:26:12 | gevaerts | reacocard: what about linux? |
00:26:14 | Bagder | RoCkEr: yes please. Eh that's a question? |
00:26:20 | rasher | reacocard: + is for read+write |
00:26:21 | bluebrother | 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 | kugel | I entered it when creating a RockboxDB object, but not when creating a RockboxDBTag one for testing |
00:26:32 | reacocard | rasher: ah, of course |
00:26:47 | RoCkEr | is ipodlinux available for classic? |
00:26:48 | amiconn | Nico_P: There is one for this bug... fs #9093 |
00:26:59 | rasher | RoCkEr: Go ask them. |
00:27:02 | Bagder | RoCkEr: nope |
00:27:14 | * | kugel liked rasher's answer more |
00:27:15 | RoCkEr | that bites |
00:27:17 | Bagder | I hear their site is hard to find ;-) |
00:27:37 | RoCkEr | yep |
00:27:37 | | Quit bertrik ("Leaving") |
00:28:10 | RoCkEr | Bagder: thanks anyway |
00:28:16 | bluebrother | I hear they have an irc channel :) |
00:28:29 | RoCkEr | what is it? |
00:28:30 | kugel | reacocard: Good to know I can ignore the 2bytes |
00:28:37 | kugel | at least for reading |
00:28:56 | reacocard | kugel: heh, just be careful when you ignore stuff. it tends to bite you if youre not careful >.< |
00:29:29 | kugel | reacocard: I mean, I'm reading them, but I don't do anything with the master index |
00:29:38 | RoCkEr | 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 | reacocard | yeah, I dont do anything cross-db yet. thats the next step now ^___^ |
00:30:11 | kugel | I'll surely take care if my program happens to write the database |
00:31:03 | saratoga | 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 | kugel | reacocard: New entries can just be appended to the tcd files, correct? |
00:31:18 | reacocard | kugel: I believe so yes |
00:31:35 | saratoga | 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 | kugel | reacocard: can you tell how the database version byte is needed? |
00:32:09 | amiconn | saratoga: When the same codec is used twice, it's not reloaded |
00:32:10 | reacocard | kugel: when the db format changes I think it increments |
00:32:25 | reacocard | so its just a way to check for compat |
00:32:37 | | Quit waldo (Remote closed the connection) |
00:32:39 | saratoga | does reloading do additional initialization? |
00:33:25 | kugel | Seems to have changed a lot then |
00:33:33 | reacocard | yeah that was my thought |
00:33:43 | * | kugel doubts that |
00:33:59 | RoCkEr | exit |
00:34:02 | reacocard | 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 | Nico_P | 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 | saratoga | oh wow! |
00:36:32 | Nico_P | well, init_mad is called again, but not codec_init |
00:36:43 | saratoga | 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 | kugel | reacocard: /* Tag Cache Header version 'TCHxx'. Increment when changing internal structures. */ |
00:38:52 | kugel | #define TAGCACHE_MAGIC 0x5443480c |
00:39:05 | saratoga | alright works nicely now |
00:39:06 | reacocard | yep, thats what I thought |
00:39:18 | reacocard | so someone mustve jsut thought it would be fun to use a really high value |
00:39:43 | kugel | reacocard: Well, then we're reading it wrong. I think it should read something with TCH |
00:39:59 | reacocard | hm |
00:40:46 | reacocard | well no, TCH is bigger than the size of that int |
00:40:47 | Nico_P | saratoga: nice :) |
00:41:06 | reacocard | TCH is three bytes but its a two-byte value |
00:41:31 | amiconn | 0x5443480c *is* TCHx (with x == 0x0c == 12) |
00:41:40 | Nico_P | saratoga: have you seen noticeable improvements from this? |
00:42:07 | kugel | reacocard: it's 4byte |
00:42:20 | saratoga | Nico_P: I have to turn on the EQ to get it to boost |
00:42:24 | saratoga | so thats nice |
00:42:28 | Nico_P | indeed |
00:42:31 | reacocard | agh |
00:42:42 | * | reacocard should stop relying on his memory when hes distracted |
00:43:16 | reacocard | yeah 0x5443480c & 0x000000ff gives 12 |
00:43:20 | saratoga | Nico_P: about 35% boost with all the EQ stuff flipped on |
00:43:21 | reacocard | which is reasonable |
00:43:37 | Llorean | saratoga: What are you testing on? |
00:44:06 | saratoga | Sansa e200 with LAME -V2 mp3s |
00:44:14 | gevaerts | saratoga: how much boost does it give with a standard build? |
00:44:21 | scorche|sh | 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 | saratoga | gevaerts: i think around 25-30% |
00:45:00 | Llorean | 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 | saratoga | 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 | amiconn | 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 | mcuelenaere | scorche|sh: yes |
00:55:22 | EricPierce | 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 | scorche|sh | mcuelenaere: so why were you after the current code if it is not going to be used? |
00:55:48 | saratoga | updated FS #9318 |
00:56:06 | mcuelenaere | scorche|sh: why is it not going to be used? (I'm talking about the rbutil*.php files) |
00:56:09 | saratoga | should work on PP502X where X> 0 |
00:56:21 | scorche|sh | mcuelenaere: ah... |
00:56:29 | | Quit amiconn (" reboot") |
00:56:31 | gevaerts | EricPierce: I'll get on to it |
00:57:13 | scorche|sh | 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 | mcuelenaere | no, not necessarily now; it's rather low-priority |
00:57:55 | mcuelenaere | perhaps someone else has the files too? |
00:58:50 | scorche|sh | 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 | gevaerts | EricPierce: should be done. Now please don't spam :) |
00:59:15 | gevaerts | Nice to see more c200 themes by the way |
00:59:26 | EricPierce | yeah, my thought exactly when I visited that page. |
00:59:29 | EricPierce | thanks a lot! |
00:59:45 | | Quit saratoga ("CGI:IRC") |
01:00 |
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 | mcuelenaere | 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 | amiconn | 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 | amiconn | I don't think we need such a suophisticated method though |
01:09:54 | gevaerts | 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 | saratoga3 | _hc: check the wiki, but i don't recall anyone looking into it |
01:39:56 | advcomp2019 | _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 | n1s | 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:00 |
02:05:38 | saratoga3 | unless they've posted the source code for what they run, thats not so important |
02:06:06 | saratoga3 | 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 | xovious | hi anyone here |
02:22:12 | xovious | llo |
02:22:19 | xovious | gt |
02:22:21 | xovious | ji |
02:22:22 | xovious | i |
02:22:22 | xovious | 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 | jac0b | 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 | Unhelpful | 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 | saratoga3 | _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 |
03:00:07 | advcomp2019 | 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 | saratoga3 | 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 | saratoga3 | ah I see theres a diff for the Connect specific stuff |
03:03:12 | saratoga3 | that was nice of them |
03:03:39 | _hc | this thing has a voip chip, it has a lot of potential |
03:04:24 | n1s | _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 | saratoga3 | 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 | reacocard | 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:00 |
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 | perrikwp | 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 | reacocard | perrikwp: its on the wiki, TagcacheDBFormat, the rblib.py attachment |
04:08:11 | reacocard | I've been working on it for a couple weeks now and only managed to crack it today |
04:08:53 | reacocard | 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 | perrikwp | reacocard: that's great, I have a half-done metadata extracter made with the Mutagen python library |
04:10:40 | reacocard | 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 | reacocard | exaile* |
04:12:50 | perrikwp | 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 | reacocard | If all goes well it'll be integrated into exaile 0.3 as well, so it'll be absolutely seamless |
04:13:48 | perrikwp | reacocard: great |
04:15:03 | reacocard | 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 | perrikwp | reacocard: yeah |
04:16:13 | | Join toffe82_ [0] (n=chatzill@adsl-71-132-86-163.dsl.sntc01.pacbell.net) |
04:17:09 | Unhelpful | 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 | reacocard | 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 | reacocard | I mean its basically undocumented and a little arcane in spots, but its perfectly doable as Ive proved |
04:20:11 | Unhelpful | undocumented and arcane, that's why. also possibly a lack of one person who was both interested and capable. |
04:20:21 | reacocard | oh ****, the copy on the wiki is bad, one sec |
04:21:01 | reacocard | AUGH it got deleted T__T fortunately its just a few lines I can redo easily |
04:24:46 | reacocard | alright wiki is fixed now |
04:25:20 | reacocard | six lines make a big difference |
04:26:09 | Unhelpful | if they have the right content, they certainly can |
04:27:47 | reacocard | an entire class |
04:28:01 | reacocard | which contains like 95% of the data |
04:28:13 | reacocard | so yeah |
04:31:31 | Unhelpful | 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 | reacocard | yeah. thankfully exaile's is mostly portable. just remove a couple logging statements and change the imports |
04:32:37 | reacocard | at least the 0.3 one is that way. 0.2's is more of a mess |
04:32:57 | reacocard | 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 | Unhelpful | so, rblib.py can't create a DB, at present? |
04:34:33 | reacocard | no |
04:35:01 | reacocard | It can read adn existing one and write it back out. anything else is beyond its capacity |
04:35:10 | Unhelpful | length is a bit touchy, iirc mutagen rounds to whole seconds for mp3, unless patched |
04:35:22 | reacocard | yeah, ive noticed |
04:36:26 | Unhelpful | 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 | reacocard | indeed, if you can figure out how >.< |
04:36:54 | reacocard | their bugtracker was down last I checked |
04:37:03 | Unhelpful | oh, ick. :/ |
04:37:21 | reacocard | yeah |
04:38:08 | Unhelpful | but this is getting somewhat off-topic. less so, it looks like rblib.py completely overwrites an existing database? |
04:38:39 | reacocard | 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 | Unhelpful | right, but you can insert new Entry items into it, right? |
04:39:40 | reacocard | correct |
04:39:46 | reacocard | or modify the current ones |
04:39:49 | reacocard | or remove them |
04:40:19 | Unhelpful | so what happens if you create a new Database, don't call read, add some entries, and then try to write? |
04:40:38 | Unhelpful | s/read/parse/ |
04:40:40 | reacocard | it errors because mmap has no idea what to do with an empty file |
04:40:46 | reacocard | wait |
04:40:48 | reacocard | maybe not |
04:40:53 | reacocard | hm I shoudl try that |
04:41:02 | reacocard | it errors on read if they're empty |
04:41:28 | Unhelpful | right, but if you init(), and don't parse(), do you have something usable? |
04:41:48 | reacocard | theoretically, as long as you add an entry before you save yes |
04:41:49 | Unhelpful | could you then add entries and call write()? |
04:42:01 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
04:42:15 | Unhelpful | so it *could*, theoretically, create a *non*-empty db. we think. |
04:42:23 | reacocard | right |
04:42:26 | reacocard | im going to test that now |
04:42:36 | Unhelpful | that sounds good enough for the most common needs, to me |
04:43:07 | reacocard | yeah, btu im going to add some other stuff over it bcause this is still really raw access |
04:46:03 | Unhelpful | 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 | reacocard | 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 | num1 | _hc: rockbox doesn't run python atm |
04:49:13 | reacocard | _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 | num1 | _hc: pretty much |
04:50:34 | reacocard | 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 | reacocard | memory mroe I think |
04:51:40 | Unhelpful | _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 | reacocard | python uses a lot of mem, and more imporantly allocates it synamically |
04:51:52 | num1 | _hc: python is an intrepreted language with dynamic memory allocation |
04:51:59 | reacocard | er, dynamically |
04:52:47 | num1 | _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 | Unhelpful | 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 | Unhelpful | it may still not be *practical* on some targets |
04:56:57 | num1 | _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 | num1 | _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 | reacocard | 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 |
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 | Llorean | _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 | Llorean | And that's not a Rockbox target. |
05:02:11 | _hc | oh, I see |
05:02:25 | Llorean | 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 | Llorean | Processor speeds vary greatly, as well |
05:02:54 | Llorean | _hc: http://www.rockbox.org/twiki/bin/view/Main/DeviceChart |
05:03:49 | _hc | luckily, our targets are iPods |
05:04:30 | Llorean | 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 | Llorean | 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 | Llorean | 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 | Llorean | 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 | Llorean | 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 | Llorean | Well, many plugins only work on the so called "software codec" players |
05:08:53 | Llorean | 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 | Llorean | 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 | Unhelpful | reacocard: excellent, that's enough for me, and probably anybody else who might want to mess w/ the DB from python |
05:13:46 | reacocard | 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 | perrikwp | 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 | reacocard | perrikwp: d = Database("/some/path"); e = Entry(); e[0] = value, repeat that for all 20 values; d.append(e); d.write() |
05:16:48 | perrikwp | reacocard: thanks alot |
05:16:53 | reacocard | 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 | Unhelpful | wouldn't be hard to rework Entry to allow passing init data on instantiation |
05:19:56 | reacocard | no not really |
05:20:39 | reacocard | probably I'll let it accept a dict with tag values |
05:21:08 | reacocard | eg Entry( values = {'artist': "James"}) |
05:21:15 | reacocard | something like that |
05:23:27 | *** | Saving seen data "./dancer.seen" |
05:23:48 | Unhelpful | though, if you have a list already, you could do e[:20] = l |
05:24:50 | Unhelpful | why not inherit dict, and have it flattened to the right order by Database when it's written? |
05:25:36 | Unhelpful | 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 | reacocard | mm, true |
05:26:07 | reacocard | this was just a first implementation ^__^ |
05:26:31 | Unhelpful | something like [e.get(t, None) for t in TAGS] |
05:26:35 | reacocard | switching to dict and then just give it a flatten() method even |
05:27:09 | Unhelpful | that'd work too... is there a single reasonable default you can translate None to for each entry? |
05:27:28 | Unhelpful | you could always have a DEFAULTS that maps per-field defaults, if not |
05:27:29 | reacocard | no, but its easily delitied into two catagories |
05:27:52 | reacocard | the first 9 shoudl defualt to "<Untagged>", the remainder to 0 |
05:28:42 | Unhelpful | 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 | reacocard | alright, that soudn best so far |
05:29:25 | reacocard | I'll start improving it tomorrow, dont feel like working more tonight :) |
05:29:47 | reacocard | 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:00 |
06:11:00 | | Quit massiveH ("Leaving") |
06:28:06 | Unhelpful | 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 | Unhelpful | is one of them supposed to be not built, or not linked, for bootloader? |
06:29:24 | Unhelpful | 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:00 |
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:00 |
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 | Unhelpful | hrm, also, looks like something broke at least bootloader usb on beast @ some point. still trying to track it down :/ |
08:23:52 | B4gder | hey, careful, that could be considered helpful ;-P |
08:24:10 | | Part toffe82_ |
08:24:20 | Unhelpful | fine, i'll stop doing a tedious binary search of subversion revisions? |
08:24:55 | Unhelpful | 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 | B4gder | yeah, binary searches is of course a lot more fun with the entire history stored locally |
08:25:53 | GodEater | and with 'git bisect' too |
08:26:43 | Unhelpful | B4gder: well, 20/20 hindsight. foresight must need new glasses. |
08:28:58 | Unhelpful | but i'd say usb or ata is to blame, as i can't even modify the partition table |
08:29:46 | GodEater | Unhelpful: is this with a bootloader built recently ? |
08:29:46 | Unhelpful | 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 | Unhelpful | 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 | LinusN | did you build the bootloader from an unpatched source? |
08:31:15 | GodEater | how is your not being able to modify the MBR manifesting itself ? |
08:32:48 | | Quit _hc () |
08:33:30 | Unhelpful | 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 | Unhelpful | 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 | GodEater | 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 | Unhelpful | i never grabbed the git repo, i only vaguely remember it being mentioned in here |
08:36:49 | Unhelpful | 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 | B4gder | 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 | B4gder | but it is hard to find ;-) |
08:40:34 | Unhelpful | right, which is why cloning it from the svn would be rather rude |
08:40:49 | Unhelpful | git is designed around cloning the entire history. svn is... not. |
08:41:05 | GodEater | B4gder: didn't we modify the GitVersionControl wiki page with the details of the one you set up ? |
08:41:10 | GodEater | or did we invent a new page ? |
08:41:30 | B4gder | 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 | GodEater | searching only turns up Nico_p's repo |
08:42:31 | GodEater | and I'm not sure he's bothering to keep it up to date these days |
08:43:28 | GodEater | I could have sworn we documented it somewhere |
08:44:41 | * | GodEater gets his S working again successfully |
08:44:48 | GodEater | this is with a bootloader from yesterday btw |
08:45:30 | | Quit Rob2223 (Read error: 60 (Operation timed out)) |
08:47:17 | Unhelpful | GodEater: that's including writes from a host PC? |
08:47:27 | Unhelpful | mine's fine til it write via USB |
08:47:46 | GodEater | well I had to write to it |
08:47:57 | GodEater | so I could mount it, and then unzip a rockbox build to it |
08:48:34 | Unhelpful | strange. |
08:50:19 | Unhelpful | my bisect is done, r18237 appears to breaks block write via USB for me. |
08:54:58 | Unhelpful | 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:00 |
09:05:34 | GodEater | hmmm |
09:05:50 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
09:05:59 | GodEater | I'd venture to say that perhaps I was a bit quick with the test of LinusN's ata patch yesterday |
09:06:06 | GodEater | it looks like it's hosed the filesystem |
09:06:42 | LinusN | cool! :-) |
09:07:08 | GodEater | reading seems ok - but writing is bad =/ |
09:09:15 | Unhelpful | GodEater: try w/o the patch. writes corrupt for me w/ r18327 unpatched |
09:09:30 | GodEater | 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 | LinusN | i have a hard time believing that my patch caused that |
09:10:21 | Unhelpful | 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 | GodEater | I think it's more likely that mkfs.vfat doesn't like the weird partition tabke |
09:10:46 | GodEater | *table |
09:11:23 | GodEater | I guess TFAT and VFAT are sufficiently unalike that the OF can always tell |
09:11:23 | Unhelpful | possibly |
09:11:56 | Unhelpful | quite likely. unfortunately, afaik nothing but WinCE itself supports TFAT |
09:12:18 | Unhelpful | ...and i still think what the tech doc describes sounds a lot like what i remember of Tux2 |
09:13:07 | Unhelpful | 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 | GodEater | 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 | Unhelpful | GodEater: add them to fstab, mine mount as /media/gigabeat and /media/gigabeat_boot |
09:17:31 | Unhelpful | ok, newest is broken for me, newest w/ r18327 reversed works. |
09:18:09 | B4gder | and now the most important question: who is to blame? who committed r18327? |
09:18:23 | * | GodEater blames perl |
09:18:41 | GodEater | Unhelpful: if I add them to fstab, then hal refuses to automount them |
09:19:12 | Unhelpful | GodEater: i can never get that HAL stuff to work entirely right, anyway? must be because i use gentoo... |
09:19:17 | amiconn | B4gder: gevaerts did |
09:19:57 | Unhelpful | well, it looks like the problem it was intended to fix was on e/c200 |
09:20:13 | amiconn | 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 | GodEater | Unhelpful: another reason to give up with gentoo then ;) |
09:21:13 | amiconn | I don't *trust* it on PP either, although I didn't perform tests myself so far |
09:22:17 | Unhelpful | bah, flipping file not found :/ |
09:23:33 | *** | Saving seen data "./dancer.seen" |
09:27:11 | Unhelpful | 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 | Unhelpful | *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 | Unhelpful | 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 | funman_ | http://paste.ubuntu.com/41152/ |
09:52:47 | funman_ | I use this patch on apps/plugins/mp3_encoder.c to be able to use it in the simulator |
09:53:06 | funman_ | on x86_64, sizeof(long)==8 so it can not be used to cast a char[4] |
09:53:30 | B4gder | uh, nasty typecast |
09:54:13 | funman_ | I would compare each char one by one, the code using it doesn't need critical speed |
09:54:34 | Unhelpful | could use uint32_t, or int32_t |
09:54:35 | B4gder | the code assumes that string is aligned too |
09:54:44 | B4gder | but I bet it always is |
09:55:09 | B4gder | memcmp should be used imho |
09:55:16 | funman_ | the string is on the stack |
09:55:38 | B4gder | the string pointer is, yes |
09:56:00 | funman_ | what about for(i=0;i<4;i++) ? |
09:56:19 | funman_ | it adds no dependancy |
09:56:25 | Unhelpful | 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 | B4gder | memcmp() exists in the plugin api already |
09:56:48 | funman_ | ok |
09:58:06 | B4gder | return !rb->memcmp(tmp, string, 4); perhaps ? |
10:00 |
10:00:57 | B4gder | uh temp, not tmp |
10:01:01 | Unhelpful | GodEater: hey, i got mkdosfs to work. and it seems to reliably avoid the beast file-not-found error. |
10:02:00 | funman_ | B4gder: indeed, it runs fine |
10:02:15 | B4gder | I'll commit that then, thanks! |
10:02:43 | funman_ | you're welcome, that's a small contribution .. |
10:03:00 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
10:03:11 | funman_ | I would rather submit you with some code for e200v2 :P |
10:03:36 | B4gder | haha, yes please! ;-) |
10:08:42 | Unhelpful | for any other S owners, i used mkdosfs -f 2 -F 32 -S 512 -s 64 -n TFAT |
10:09:14 | Unhelpful | 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 | Unhelpful | 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 | GodEater | Unhelpful: could you add that to the wiki please ? |
10:36:19 | Unhelpful | erm, i can't at present, on account of not having requested write access as of yet. |
10:40:28 | Unhelpful | whenever somebody can grant write access to AndrewMahone, i'll be happy to add it... i'd guess to GigabeatSInstallation? |
10:40:43 | B4gder | 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 | gevaerts | 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 | Unhelpful | 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 | gevaerts | Right now, nowhere (I forgot to initialise a pointer on non-PP) |
10:45:39 | gevaerts | http://pastebin.ca/1187204 should fix it |
10:45:48 | Unhelpful | 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 | gevaerts | (totally untested, hopefully it compiles) |
10:46:02 | Unhelpful | heh. |
10:47:08 | Unhelpful | i have a bit of work to get through here, then i can build+test |
10:52:17 | funman_ | anything preventing recording from mic/fm in the simulator, besides "not tested" ? |
10:52:40 | Unhelpful | 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 | Unhelpful | 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 |
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 | amiconn | 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 | gevaerts | 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 | MartinR | gevaerts: I really think the sansa bug should be fixed (worked around) at the driver side, not at the USB side. |
11:13:40 | MartinR | gevaerts: Calculating the cached address would be easy, but I'm uncertain about the cache handling. |
11:14:09 | pixelma | Bagder: did you already have a chance to see what's up with the coldfire and sh daily builds? |
11:14:25 | LinusN | is there a problem? |
11:17:09 | gevaerts | 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 | LinusN | do we use the driver for anything in the 3.0 targets? |
11:18:35 | LinusN | pixelma: what's the problem with the daily builds? |
11:18:37 | gevaerts | I mean the sd driver. This is the corruption issue |
11:18:46 | gevaerts | So yes, we use that |
11:18:48 | LinusN | aha |
11:19:09 | | Join snoh [0] (n=dave@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) |
11:19:11 | LinusN | if the sd driver corrupts the file system, i consider it a 3.0 showstopper |
11:19:12 | pixelma | 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 | MartinR | 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 | gevaerts | LinusN: it only does it when used from the usb stack. Nobody has yet seen any issue within rockbox |
11:20:05 | LinusN | pixelma: ah, now i see, i was looking at the wrong builds |
11:20:21 | LinusN | gevaerts: aha, i see |
11:20:30 | pixelma | LinusN: and if you look at the table, it seems quite obvious that it started with the server crash |
11:21:02 | pixelma | Bagder already tried some things which brought back parts of it |
11:21:27 | amiconn | LinusN: The sd driver occasionally corrupts data when writing. Changing the write loop changes the frequency of that happening |
11:21:39 | pixelma | LinusN: (like e.g. the voice files which were missing at the beginning too) |
11:21:46 | amiconn | I guess there's some register we're not setting correctly |
11:21:55 | LinusN | 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 | LinusN | :-) |
11:23:34 | *** | Saving seen data "./dancer.seen" |
11:24:54 | amiconn | LinusN: It can basically happen any time. Not only when recording, but also when saving playlists, or .playlist_control etc |
11:25:15 | LinusN | ah, of course |
11:25:59 | gevaerts | 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 | pixelma | didn't someone test writing (copy+pasting inside Rockbox)? But maybe that was with some patch, don't remember exactly... :\ |
11:26:53 | gevaerts | pixelma: yes. I've basically asked everyone who reported corruption on usb write to test that. Nobody had any issues there |
11:27:47 | amiconn | Also boosted? |
11:28:23 | * | gevaerts checks the FS #8663 log |
11:29:03 | amiconn | When experimenting with an optimised write loop, it worked nicely at 30MHz, but caused problems at 80MHz |
11:29:12 | LinusN | pixelma: bug found - rebuilding dailies |
11:29:19 | MartinR | amiconn: Yes, I also tried copying when boosted. No cooruption. |
11:30:26 | amiconn | How much data did you try? |
11:30:59 | * | MartinR checks the FS #8663 log :) |
11:31:24 | amiconn | 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 | amiconn | You can also modify test_disk to use the sd card |
11:32:35 | pixelma | LinusN: nice, thanks :) |
11:32:55 | LinusN | no, thank *you* for reporting :-) |
11:33:42 | MartinR | I used a directory of 415 MB (95 files) then. But will try test_disk soon. |
11:36:23 | MartinR | But I think it's rather coincidence that the bug does not appear on internal operations. |
11:37:52 | MartinR | If that udelay is changed slightly, it does also then. |
11:38:27 | amiconn | Yes, and that's what makes me think there's something fundamentally wrong |
11:39:20 | LinusN | would some logic analysis help? |
11:39:49 | LinusN | or is it internal, like a caching issue? |
11:41:58 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
11:43:58 | MartinR | Hard to say what kind of issue this might be. |
11:43:58 | Unhelpful | 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 | gevaerts | 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 | gevaerts | test_disk is basically the same there, but both usb and recording are more complex |
11:45:01 | amiconn | LinusN: I think it's a timing issue. We need to find the missing register setting(s) |
11:45:26 | gevaerts | So I suspect that if we see corruption without usb, it will be while recording (or maybe with playlists) |
11:47:52 | MartinR | I already poked around in the bootloader code, but found nothing that we're missing. |
11:48:42 | MartinR | 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 | gevaerts | That's only the bootloader though. Do we know if the OF sd driver is in iram, if the data is in iram, ... ? |
12:00 |
12:06:29 | MartinR | 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 | MartinR | 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 | kerrorizer | hello gyus can someone help me ? |
12:14:50 | kerrorizer | i want to ask where will be able ROCKBOX for CREATIVE ZEN |
12:15:30 | | Quit kerrorizer (Client Quit) |
12:18:20 | ender` | now that's some patience :) |
12:18:45 | GodEater | 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 | aart3k | hi |
12:31:45 | aart3k | does Rockbox still work with compactflash based ipods? |
12:31:56 | | Quit Seed ("cu, Andre") |
12:32:10 | GodEater | should do |
12:32:14 | aart3k | for me bootloader doesn't work on 2g mini with 8gb cf |
12:32:20 | aart3k | by transcend |
12:32:26 | aart3k | original firmware works |
12:32:30 | GodEater | well the cards have seemed to vary a lot |
12:32:55 | aart3k | it seems that bootloader is unable to mount partitions |
12:33:31 | wpyh | hm.... |
12:33:44 | wpyh | if the OF works, then there must be a bug IMO |
12:33:53 | aart3k | No partition found |
12:34:03 | wpyh | yeah |
12:34:17 | linuxstb | 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 | aart3k | disk_mount_all() gives zero or something, i didnt debug |
12:34:55 | wpyh | linuxstb: does the build for the mini include FAT32 support? |
12:35:06 | wpyh | but it should... hm... |
12:35:25 | aart3k | diff that i've found on wiki doesn't seem to be useful with stuff that bootloader uses |
12:35:39 | aart3k | so i didnt compile |
12:36:03 | wpyh | uh... seems the other way around |
12:36:07 | linuxstb | 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 | wpyh | (I'm talking to myself) |
12:36:34 | wpyh | linuxstb: yeah, I got it reversed |
12:36:47 | wpyh | aart3k: did you format it as FAT16 or as FAT32? |
12:37:34 | amiconn | You cannot format 8GB as fat16 |
12:37:41 | aart3k | fat32 |
12:38:14 | aart3k | i've just restored it using itunes |
12:38:21 | wpyh | amiconn has a point |
12:39:02 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
12:39:08 | wpyh | 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 | aart3k | so i need to debug by myself |
12:40:25 | aart3k | damn ;) |
12:41:17 | aart3k | i'll be back at evening, maybe i'll see some results |
12:41:33 | aart3k | but first of all i'll try to format patrition as fat16 |
12:41:51 | aart3k | anyways seeya guys, thanks for helping |
12:42:38 | wpyh | 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 | krz_ | heloo all |
12:47:07 | krz_ | *hello :) |
12:53:29 | | Join ZincAlloy [0] (n=d9eee040@gateway/web/cgi-irc/labb.contactor.se/x-6f12471e39a7b8f3) |
12:54:15 | krz_ | are there any of SVN admins? |
12:54:33 | linuxstb | krz_: What do you need? |
12:55:55 | krz_ | 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 | B4gder | so there's an updated patch in the tracker? |
12:58:43 | linuxstb | krz_: Does your patch make many changes to the core Rockbox code? |
12:59:00 | * | linuxstb goes to find the patch |
12:59:21 | krz_ | B4gder: no updates from yesterday |
12:59:53 | | Quit funman_ (Read error: 104 (Connection reset by peer)) |
13:00 |
13:00:05 | | Join moos [0] (i=moos@81-66-127-205.rev.numericable.fr) |
13:00:13 | krz_ | linuxstb: there are some changes made via ifdefs. it was tested on rockbox build and seems that it doesnt breack anything |
13:00:24 | linuxstb | krz_: Looking at your patch quickly now, you're making unwanted whitespace changes - e.g. doing things like "# define" (adding spaces) |
13:01:10 | krz_ | linuxstb: so, this is unwanted? it helps great to read the code |
13:01:23 | linuxstb | Read the coding guidelines in docs/CONTRIBUTING |
13:01:35 | B4gder | unrelated changes are always bad |
13:01:44 | krz_ | linuxstb: anything else? |
13:01:45 | B4gder | since it makes reading the patch harder |
13:01:45 | linuxstb | The basic principle is to always keep the formatting the same as the file you're editing. |
13:02:02 | B4gder | what's the fs#? |
13:02:06 | linuxstb | And as B4gder said, don't include whitespace changes in functional patches |
13:02:10 | linuxstb | 9327 |
13:02:22 | | Join funman [0] (n=tg@82-171-216-191.ip.telfort.nl) |
13:03:01 | linuxstb | i.e. if you want to make whitespace changes, make a patch with only whitespace changes. |
13:03:33 | B4gder | I can see tabs in the code |
13:05:20 | krz_ | and what about code changes? |
13:07:17 | linuxstb | 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 | krz_ | linuxstb: ok,sure |
13:07:43 | | Join funman_ [0] (n=tg@82-171-216-191.ip.telfort.nl) |
13:07:45 | linuxstb | 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 | krz_ | 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 | B4gder | it will be needed |
13:11:20 | B4gder | 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 | linuxstb | 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 | krz_ | 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 | GodEater | 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 | gevaerts | Looks impressive though :) |
13:42:08 | GodEater | 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 | kugel | 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:00 |
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 | Nico_P | 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 | linuxstb | Nico_P: I'm curious about it... e.g. to see how it affects runtime on a current target. |
14:08:46 | Nico_P | 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 | krz_ | linuxstb: so, what do you think about making wpseditor to run from console like checkwps? |
14:15:10 | linuxstb | 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 | Nico_P | linuxstb: http://pastebin.ca/1180832 in case you want to give it a try |
14:16:22 | linuxstb | 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 | Nico_P | linuxstb: I think I'll put it up on flyspray so that someone can maybe do a runtime test |
14:17:50 | linuxstb | How much RAM does it use? What about storing metadata? |
14:17:55 | linuxstb | (and album-art?) |
14:18:54 | Nico_P | 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 | Nico_P | 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 | gevaerts | If it doesn't have too many disadvantages, you could also use it to increase the plugin RAM a lot |
14:22:10 | Nico_P | it would sure be nice to know what kind of impact it has on runtime |
14:29:16 | krz_ | 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 | krz_ | btw checkwps doesn't compile for cowon and mrobe500 |
14:30:16 | linuxstb | 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 | linuxstb | 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 | B4gder | we should perhaps build checkwps for the specific target as part of the normal build |
14:32:03 | B4gder | that will make sure it remains building |
14:32:16 | B4gder | buildable I mean |
14:33:31 | krz_ | it doesn't build for all targs now. on mingw at least |
14:33:44 | B4gder | yeps, I noticed that too |
14:34:02 | B4gder | 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 | linuxstb | 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 | B4gder | then that sounds reasonable, yes |
14:37:06 | krz_ | linuxstb: fs9327 here is rockbox_changes3 |
14:37:19 | krz_ | btw it includes fixes for checkwps |
14:37:20 | linuxstb | OK, I'll commit that. |
14:37:32 | linuxstb | I meant moving BOM_SIZE and BOM into misc.c... |
14:38:30 | krz_ | 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 | linuxstb | 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 | linuxstb | 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 | krz_ | linuxstb: il make if defined then :) |
14:55:35 | krz_ | *i'll |
14:56:02 | kugel | krz_: is it a gsoc project? |
14:56:15 | krz_ | kugel: yes |
14:56:43 | linuxstb | 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 | linuxstb | krz_: #ifdef is more commonly used in Rockbox source... |
14:58:28 | kugel | 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 | krz_ | linuxstb: so, you think they can be included not only in ifdef __PCTOOL__? |
15:00 |
15:00:03 | linuxstb | krz_: Yes, I think so. |
15:00:26 | JUSTWJX | markun,what's going on with meizu M6? |
15:00:39 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
15:03:24 | kugel | krz_: I wonder why you have your own checkwps in the editor, is the rockbox one not good? |
15:03:41 | JUSTWJX | :-( |
15:04:39 | gevaerts | JUSTWJX: Please don't ask for progress reports here. Everything that happens is reported on the forums. |
15:04:48 | krz_ | kugel: it is a bit different |
15:05:13 | kugel | krz_: Has it the same purpose? |
15:06:05 | JUSTWJX | right~ |
15:06:27 | | Join phinze [0] (n=phinze@pool-96-250-252-230.nycmny.fios.verizon.net) |
15:06:28 | krz_ | kugel: i've reimplemened some functions from original checkwps |
15:06:56 | kugel | 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 | kugel | krz_: So, what's the difference between your and the normal checkwps? |
15:10:49 | krz_ | kugel: as i have said i've reimplemened some functions from original checkwps. and i use some of the original ones |
15:11:59 | kugel | krz_: I've read that. I wonder why you made another one, so I asked you what the differences are |
15:12:40 | krz_ | kugel: i mentioned the difference |
15:13:47 | gevaerts | krz_: not really. You said that there is one, not why |
15:15:01 | krz_ | 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 | kugel | " i've reimplemened some functions" is hardly a meaningful difference for me |
15:15:34 | kugel | 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 | krz_ | kugel: i don't use it now for checking wps. |
15:21:45 | kugel | 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 | krz_ | 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 | kugel | So, it has a different purpose? That at least answers my initial question |
15:25:02 | gevaerts | krz_: if you have a checkwps function that doesn't check a wps, then yes, please rename it |
15:25:45 | krz_ | kugel: no, it doesn't have a different propose |
15:26:48 | kugel | So it has the same purpose? |
15:27:52 | krz_ | yes |
15:27:56 | kugel | 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 | kugel | that doesn't make sense to me |
15:28:16 | | Quit funman_ (Read error: 104 (Connection reset by peer)) |
15:28:59 | krz_ | 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 | kugel | 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 | krz_ | kugel: so, you propose to include original checkwps.c to my build? |
15:35:10 | kugel | yes, either build-in or as an external app called by your editor |
15:36:57 | krz_ | 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 | kugel | I don't know |
15:43:25 | kugel | 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 | gevaerts | 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 | gevaerts | size has nothing to do with it |
15:45:55 | krz_ | kugel: so, linker will give errors |
15:46:28 | krz_ | 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 | krz_ | linuxstb: thanks :) |
15:48:55 | kugel | 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 | linuxstb | But maybe the common code from wpseditor and checkwps could be factored out to a common place... |
15:49:41 | GodEater | libwps ? |
15:49:42 | GodEater | :) |
15:50:12 | kugel | 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 | krz_ | so |
15:52:04 | kugel | krz_: How do you find my proposal? |
15:52:06 | krz_ | should i refactor or leave all behind? |
15:54:19 | krz_ | kugel: i'd perefer not to make it complex |
15:55:08 | kugel | krz_: calling an external app is complex? |
15:55:38 | gevaerts | 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 | krz_ | wpseditor->emacs :) |
15:58:29 | linuxstb | 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 | kugel | linuxstb: but then the wps editor should at least offer a llittle cli to check wpses (for the theme site) |
15:59:59 | krz_ | linuxstb: as i mentioned above, it can replace checkwps |
16:00 |
16:00:15 | gevaerts | kugel: sure, but that's not infeasible |
16:00:49 | kugel | gevaerts: yea, I could live with it then :) |
16:01:22 | krz_ | so... are current changes acceptable? |
16:04:11 | kugel | from what I've understand: no, but this can be done after committing |
16:05:33 | gevaerts | 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 | krz_ | as far as i understood from today's talk, in near future wpseditor can replace checkwps(or can be refactored) |
16:08:09 | krz_ | but what are te oher problems? |
16:12:07 | gevaerts | 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 | krz_ | gevaerts: you mean in makefile? |
16:15:05 | | Join _hc [0] (n=hanschri@ool-182d0a7f.dyn.optonline.net) |
16:15:12 | gevaerts | krz_: actually, I'm looking now. Whyni |
16:15:31 | gevaerts | 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 | krz_ | gevaerts: actually i don't need all that funcs in wpseditor, and i didn't want to include additional headers |
16:17:57 | gevaerts | 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 | gevaerts | 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 | krz_ | :) i tried to remove all warnings, cause someone complained on it yesterday |
16:20:01 | krz_ | and today you say that it was ok |
16:20:03 | gevaerts | That's probably the "others may disagree" bit :) |
16:20:11 | krz_ | :) |
16:20:26 | krz_ | i'll wait for my mentor i think |
16:21:15 | | Quit wpyh ("Leaving.") |
16:21:55 | linuxstb | gevaerts: That's not really practical, as we want to squash all warnings... |
16:21:56 | gevaerts | 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 | krz_ | linuxstb: i'd also like to hear your opinion about all this |
16:23:55 | gevaerts | 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 | gevaerts | 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 | krz_ | gevaerts: jup |
16:30:18 | | Quit funman (Read error: 110 (Connection timed out)) |
16:31:52 | | Quit EspeonEefi ("さよなら") |
16:34:19 | gevaerts | 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 | krz_ | 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 | gevaerts | 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 | linuxstb | gevaerts: They're tabs... |
16:56:41 | krz_ | oops |
16:56:48 | _emp | linuxstb, I got openBSD working. |
16:57:23 | linuxstb | _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 | krz_ | gevaerts: fixed, new patch is coming .. :) |
16:59:56 | linuxstb | gevaerts: kill, kill, kill... |
17:00 |
17:00:11 | krz_ | btw, why does everyone so dislike tabs? |
17:00:54 | gevaerts | 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 | linuxstb | 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 | linuxstb | 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 | linuxstb | 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 | saratoga | linuxstb: I have not heard anything about that |
17:06:15 | linuxstb | saratoga: See here - http://www.rockbox.org/irc/log-20080827#09:13:44 |
17:06:46 | saratoga | linuxstb: how is eligable to write the evalutation? |
17:06:53 | saratoga | who |
17:07:08 | linuxstb | I've no idea... |
17:07:14 | | Join Nibbler [0] (n=Nibbler@91-67-150-33-dynip.superkabel.de) |
17:08:01 | linuxstb | You didn't have a backup mentor... |
17:09:02 | saratoga | 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 | saratoga | 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 | LambdaCalculus37 | saratoga: Not yet; what's the FS#? |
17:20:23 | saratoga | FS #9318 |
17:22:45 | saratoga | i think it should save a good bit of battery lfie |
17:23:25 | LambdaCalculus37 | 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 | kugel | 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 | kugel | Hmm, how to build the wps editor? |
17:50:32 | kugel | 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:00 |
18:04:39 | kugel | 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 | kugel | 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 | kugel | krz_: hey, I need help with the wps editor |
18:20:38 | kugel | I guess I compiled it (qmake && make in rbutil/checkwps) but I can't open it |
18:20:41 | krz_ | kugel: so, what have you already done? |
18:21:02 | | Quit nplus (Remote closed the connection) |
18:21:04 | kugel | 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 | kugel | 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 | krz_ | kugel: try to make it from wpseditor/proxy |
18:23:34 | kugel | The file is there |
18:23:51 | kugel | ll .../bin shows gui and libproxy.so |
18:23:58 | kugel | ll = ls -l |
18:24:23 | krz_ | may be copying to gui/bin will help? |
18:24:42 | kugel | 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 | gevaerts | kugel: try going to gui/bin first. I always did it that way |
18:26:20 | kugel | i did |
18:27:16 | gevaerts | It works here |
18:27:33 | krz_ | gevaerts: have you succeded? |
18:28:15 | gevaerts | krz_: so you're in bin/, and you try running it with ./gui? |
18:28:22 | gevaerts | kugel: so you're in bin/, and you try running it with ./gui? |
18:28:32 | kugel | 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 | kugel | krz_, gevaerts: weird, isn't it? |
18:31:35 | kugel | I did "qmake ; make" to build, have I forgotton something? |
18:32:03 | * | gevaerts is confused now |
18:32:45 | krz_ | hm |
18:32:58 | * | domonoky thinks this is strange... are the permissions correct for the lib ? |
18:33:13 | gevaerts | I can reproduce the problem now |
18:33:33 | bertrik | may running ldconfig as root fixes it? |
18:33:40 | gevaerts | no |
18:34:09 | gevaerts | I had an empty path somewhere in LD_LIBRARY_PATH, which apparently means the same as '.' |
18:34:19 | domonoky | or perhaps the wrong qmake ? it may be qmake-qt4 .. |
18:35:04 | gevaerts | 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 | gevaerts | You can work around it by 'export LD_LIBRARY_PATH=.' |
18:36:07 | gevaerts | But that's not a proper solution |
18:36:12 | nutsy | 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 | kugel | gevaerts: this is temporarily, isn't it? |
18:36:40 | rasher | nutsy: Check the New Ports forum. That contains all info about this topic. |
18:37:07 | gevaerts | kugel: that's for the current shell and its subprocesses only |
18:39:12 | kugel | 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 | kugel | gevaerts: working now, thanks |
18:39:41 | | Quit Nico_P ("http://www.mibbit.com ajax IRC Client") |
18:39:50 | gevaerts | kugel: why would it copy it there? |
18:39:56 | domonoky | no the lib will be copied into the gui/bin dir... i dont know why it doesnt look there... |
18:40:55 | kugel | gevaerts: I just asked |
18:41:14 | * | domonoky checks where Qt does look for libs, on linux.. |
18:41:23 | kugel | So, krz_, now tell me how to enter .rockbox with "Open WPS" when it's hidden? |
18:41:45 | gevaerts | kugel: right-click and enable hidden things |
18:41:56 | nutsy | 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 | nutsy | is that right? |
18:42:35 | | Join MethoS [0] (n=clemens@host-091-097-240-003.ewe-ip-backbone.de) |
18:42:39 | gevaerts | 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 | nutsy | i never said it was easy |
18:43:53 | nutsy | I knew ages ago that the encrypted firmware was going to be a problem |
18:44:06 | nutsy | I just came in to see if there was any progress thats all :) |
18:44:34 | gevaerts | nutsy: I mean that some of the people on the forum are seriously underestimating this |
18:44:37 | nutsy | 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 | nutsy | ah ok |
18:45:18 | domonoky | 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 | kugel | 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 | domonoky | 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 | domonoky | but that isnt important for this first commit.. |
18:47:35 | kugel | 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 | domonoky | 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 | krz_ | kugel: i conserned on H10 5gb |
18:47:59 | * | gevaerts is trying to find a way to make it work |
18:48:31 | kugel | krz_: Nice that you don't mention this anywhere |
18:49:19 | kugel | krz_: Anyway, besides that, it seems to work nicely. Good job. |
18:49:40 | kugel | TODO: use real fonts for the preview |
18:49:41 | krz_ | kugel: thnx |
18:50:01 | kugel | 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 | domonoky | 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 | domonoky | so its: QLibrary lib( currentPath() + "/proxy"); |
18:51:34 | krz_ | kugel: you can help with this after commiting, or you can create a patch |
18:52:23 | kugel | krz_: Yea. It wasn't meant as a request (rather a suggestion for later), don't get me wrong. |
18:53:04 | domonoky | 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 | domonoky | so its important that at leats all changes to rockbox code are properly discussed here.. |
18:53:52 | gevaerts | domonoky: currentPath() doesn't seem to compile |
18:53:53 | domonoky | s/leats/least/ |
18:53:58 | kugel | 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 | domonoky | oh, its QDir::currentPath() |
18:55:06 | domonoky | 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 | kugel | domonoky: creating a branch? Will it not be in the normal source? |
18:59:05 | gevaerts | kugel: a week before the release? |
18:59:24 | kugel | ah, forgot about the freeze |
18:59:34 | gevaerts | How do you build this with debug symbols? |
19:00 |
19:01:18 | superkaybee | does anyone have the pictureflow demo working on a sansa? |
19:02:11 | domonoky | 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 | gevaerts | domonoky: gui, mainly |
19:02:50 | * | gevaerts gets segfaults |
19:04:30 | domonoky | gevaerts: change the CONFIG line in gui.pro to mention "debug" (but then you need a Qt build in debug mode) |
19:06:14 | krz_ | btw, won't debug_and_release work? |
19:06:56 | | Quit stu8ball_ (Read error: 110 (Connection timed out)) |
19:07:41 | domonoky | 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 | gevaerts | How do you print a line ? |
19:08:14 | | Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) |
19:08:20 | krz_ | domonoky: will "./proxy" work instead currentPath() on lunux? |
19:08:22 | * | gevaerts is a Qt-newbie |
19:09:38 | gevaerts | krz_: apparently it does, but that doesn't solve this entirely |
19:09:41 | domonoky | krz_: QLibrary mentions absolute Paths... |
19:09:51 | gevaerts | 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 | domonoky | otherwise it uses the normal system libray paths.. |
19:10:22 | krz_ | ah |
19:10:33 | gevaerts | Which also means that currentPath() isn't the correct solution |
19:10:46 | domonoky | gevaerts: QDir()::currentPath() is always the adfs.kja |
19:10:49 | domonoky | ups |
19:11:17 | * | gevaerts doesn't entirely understand that |
19:11:40 | * | domonoky has keyboard problems, maybe batterys get empty.. :-) |
19:12:21 | domonoky | currentPath is always the absolute path to the application dir, on all systems.. |
19:12:54 | domonoky | so it should be the right solution.. |
19:13:19 | * | gevaerts tries a bit more |
19:13:31 | krz_ | btw, currentPath tells working directory or dir with executable? |
19:13:46 | | Join _hc [0] (n=hanschri@209.131.113.150) |
19:14:00 | gevaerts | How do I print a line to stdout with Qt ? |
19:14:11 | domonoky | gevaerts: to print something, you can use qDebug() << "text" << somevar; |
19:14:26 | krz_ | it seems that it takes working dir, not executable |
19:14:50 | domonoky | QString QDir::currentPath ()В В [static] Returns the absolute path of the application's current directory. |
19:15:17 | gevaerts | "current directory" == working directory I think |
19:15:29 | | Join Lambdumb [0] (n=Lambda@12-202-140-90.client.mchsi.com) |
19:15:50 | krz_ | jup, and we want current dir or executable dir? |
19:15:55 | gevaerts | Maybe QCoreApplication::applicationDirPath() ? |
19:15:56 | | Quit ZincAlloy ("CGI:IRC (EOF)") |
19:16:13 | domonoky | lets check how we solve this in rbutil .-) |
19:16:28 | gevaerts | That works :) |
19:16:38 | gevaerts | krz_: so you need QLibrary lib(QCoreApplication::applicationDirPath() +"/proxy"); |
19:16:51 | krz_ | but |
19:16:52 | domonoky | QCoreApplication::instance()->applicationDirPath() is the thing we use in rbutil |
19:17:06 | krz_ | ok |
19:17:07 | | Join elinenbe [0] (i=elinenbe@76.29.222.54) |
19:17:12 | gevaerts | krz_: then remove the -lproxy from the LIBS line in gui/gui.pro |
19:17:32 | gevaerts | (otherwise you don't actually use the path from the source) |
19:17:44 | gevaerts | Then test if it still works in windows :) |
19:18:45 | gevaerts | 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 | krz_ | works |
19:18:49 | elinenbe | what's the status on 3.0? What is the ETA? |
19:19:31 | gevaerts | That may not be too important though, as it should never happen |
19:19:58 | gevaerts | elinenbe: a few weeks. No precise ETA |
19:20:24 | elinenbe | gevaerts: thanks. |
19:20:27 | domonoky | 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 | gevaerts | 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 | gevaerts | Indeed. win==0 |
19:22:42 | krz_ | jup, just fuond out that too |
19:22:50 | krz_ | *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 | gevaerts | Lear: have you seen FS #9306 ? I was pointed to you |
19:26:57 | Lear | Read it now. Sounds strange... |
19:27:31 | * | gevaerts agrees. |
19:29:31 | elinenbe | 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 | kugel | Nico_P: ping |
19:31:35 | | Join toffe82_ [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) |
19:32:05 | kugel | elinenbe: agreed |
19:33:11 | | Quit Lambdugh (Read error: 110 (Connection timed out)) |
19:33:13 | kugel | 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 | gevaerts | Surely that's not meant for commit? |
19:36:11 | | Quit _hc () |
19:37:02 | kugel | gevaerts: I haven't said it's ready for commit. I agreed to the fact that "it's oh, so nice" ;) |
19:37:19 | kugel | and it works flawlessly. Though I think the converter can be optimzed |
19:37:32 | gevaerts | kugel: the question (not yours) was "why is it not committed?" :) |
19:38:15 | kugel | anyway, remove the #if 0, and commit please :) |
19:39:33 | Lear | 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 | gevaerts | Lear: the weird thing is that this doesn't happen if you restart from a normal bookmark... |
19:40:55 | gevaerts | 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 | kugel | gevaerts: Well, I didn't. monochrome is probably unsupported |
19:41:53 | kugel | greyscale shouild work |
19:42:12 | kugel | gevaerts: if you have such a target, feel free to test! |
19:42:33 | Lear | 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 | gevaerts | 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 | gevaerts | kugel: and I don't care about this... |
19:44:33 | gevaerts | Lear: if it's timing, this will be fun... |
19:44:34 | kugel | gevaerts: I expected that. Most committer don't care about this patch |
19:44:50 | Lear | The fact that playback.c was changed in r17923 is an indication too. |
19:45:33 | Lear | gevaerts: Yeah, like the one I found recently. At first I couldn't consistently reproduce it, which made it extra fun. :) |
19:46:16 | Lear | 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 | Lear | s/playback.c/buffering.c/... |
19:47:01 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
19:47:06 | gevaerts | 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 | gevaerts | kugel: can you still do non-antialiased fonts with it? |
19:48:03 | kugel | clean up as in remove the #if 0 stuff, or is there mroe? |
19:48:28 | kugel | 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 | gevaerts | 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 | gevaerts | Nico_P: ping |
19:51:09 | | Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) |
19:52:14 | gevaerts | 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 | Nico_P | pong |
19:53:31 | Nico_P | but I'm cleaning my appartment before leaving it, so I don't have much time to offer |
19:53:35 | gevaerts | Nico_P: have you seen FS #9306 yet? |
19:54:14 | Nico_P | no, I hadn't |
19:54:34 | gevaerts | Lear thinks you may be able to help |
19:54:35 | kugel | gevaerts: ah right, I forgot about that one. The font doesn't work in the WVS |
19:54:44 | | Part virtuoso015 |
19:56:10 | gevaerts | kugel: My guess is that that sort of issue really needs to be solved |
19:56:18 | kugel | Nico_P: I'm testing the buffering patch |
19:56:29 | kugel | I'll have a runtime test available tomorrow |
19:57:14 | kugel | gevaerts: the current workaround is to use the sysfont in the wvs (the mpegplayer menu is fine= |
19:57:16 | kugel | ) |
19:57:41 | gevaerts | kugel: a workaround is fine for an optional patch, but not really for svn |
19:58:43 | kugel | gevaerts: I know |
19:59:18 | | Quit GodEater__ (Remote closed the connection) |
19:59:35 | kugel | 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 | kugel | and I didn't create the patch. Actually both, mpegplayer and the patch are a mess for me |
19:59:53 | Nico_P | kugel: thanks |
19:59:54 | gevaerts | Llorean: while viewing screen? |
20:00 |
20:00:03 | kugel | while video screen :) |
20:00:10 | Llorean | There's hardly a "while video screen" |
20:00:14 | | Quit saratoga ("CGI:IRC (EOF)") |
20:00:16 | Llorean | There's a video overlay. |
20:00:20 | Llorean | Or there's the video itself... |
20:00:56 | pixelma | but generally, I think there are much more important things concerning fonts than anti-aliasing |
20:01:00 | kugel | I remember it being called that like that when the feature was committed |
20:01:26 | kugel | 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 | gevaerts | kugel: multi-font? |
20:01:38 | Llorean | pixelma: Honestly, I think antialiasing improves very few fonts. It generally decreases readability on the players, for me. |
20:02:12 | Llorean | I'd also like to know how well the antialiasing hack works for complex unicode characters. |
20:02:26 | kugel | Llorean: true, the better readability only sets in for fonts larger than 12 or something pixel |
20:02:30 | pixelma | yeah, that too. The 2 screenshot in the forums I've seen look really blurry |
20:02:46 | gevaerts | 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 | Llorean | kugel: No, I think it actually just makes those tend to look out of focus. |
20:03:00 | Llorean | Generally, the better readability seems to be a very case by case basis for me. |
20:03:04 | kugel | gevaerts: I don't see why we should wait with the 1 font thing while waiting for another font thing |
20:03:15 | Llorean | kugel: In case they conflict. |
20:03:20 | Llorean | Multifont is a higher priority. |
20:03:33 | pixelma | kugel: the ability to use at least 2 different fonts for remote and main screen (or mulitfont in general) |
20:03:43 | kugel | so, rockbox is stalling until multifont? |
20:03:51 | gevaerts | yes :) |
20:04:05 | pixelma | of course... |
20:04:06 | * | gevaerts won't commit anything until multifont is ready |
20:04:30 | Llorean | kugel: Why does "maybe we should wait on antialiasing, a trivial feature that might conflict" mean "Rockbox is stalling"? |
20:05:00 | pixelma | but actually I wanted to "oh noe" at the anti-aliasing question again... :\ |
20:05:07 | gevaerts | 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 | kugel | 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 | kugel | and it works well with the multifont patch on the tracker |
20:07:11 | Llorean | You mean the one that hasn't been committed because it's not done right? |
20:07:36 | Bagder | speaking of stalling, are we up for a release branch done this weekend? |
20:07:52 | kugel | 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 | kugel | Llorean: yes |
20:08:13 | Llorean | 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 | Llorean | 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 | Bagder | 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 | gevaerts | Let's do it. We can still backport more important fixes if they happen before the release |
20:09:19 | Bagder | exactly |
20:09:21 | Llorean | 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 | pixelma | 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 | Llorean | And the playlist thing hardly has anyone complaining about it, so obviously it's not *that* major. |
20:09:40 | kugel | 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 | Llorean | kugel: How much does AAF increase BIN and RAM usage, anyway? |
20:10:41 | kugel | I haven't done any measures. geaverts said it adds ~1400 ram |
20:10:56 | pixelma | Llorean: which playlist bug are you talking about? |
20:11:06 | kugel | but if the creator is right, and it also speeds up font rendering, I'd say it's definetely worth it |
20:11:46 | Llorean | pixelma: One associated with moving files and having the cursor end up in the wrong place |
20:12:02 | Llorean | kugel: Or we could take the font rendering speed increase, and drop the RAM waste... |
20:12:17 | Llorean | 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 | gevaerts | rockbox-info.txt without AA : http://pastebin.ca/1187661 , with AA : http://pastebin.ca/1187662 |
20:12:37 | kugel | Llorean: Why do you think the RAM is "wasted" by the anti-aliased only? |
20:13:30 | Llorean | kugel: Feel free to demonstrate otherwise, then. |
20:14:02 | kugel | Llorean: Why should I? You've made the assumption, and I want both |
20:14:13 | pixelma | Llorean: ok, I know that one (and commented on) |
20:14:15 | Llorean | kugel: And you have to justify the patch. |
20:14:26 | Llorean | 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 | Llorean | gevaerts: That bit's obvious though. |
20:15:49 | Llorean | 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 | Llorean | pixelma: But if necessary, the fix for it can prompt a 3.0.1 or something. |
20:16:11 | gevaerts | 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 | kugel | 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 | pixelma | Llorean: yes, it's quite annoying |
20:17:23 | pondlife | pixelma: Can you repro the playlist problem at all? |
20:17:33 | pondlife | I couldn't |
20:17:47 | pixelma | pondlife: yep, see last comment |
20:17:58 | pondlife | Ah, on Flyspray? |
20:18:00 | kugel | I find it sad, that there's so much prejudice about AAF. |
20:18:15 | Llorean | kugel: Prejudice? |
20:18:22 | Llorean | Are you aware of what the word actually means? |
20:18:31 | Bagder | I would like to see AAF done |
20:18:33 | pixelma | pondlife: http://www.rockbox.org/tracker/task/7967 |
20:18:42 | kugel | Llorean: yes I do |
20:18:44 | Bagder | but I'm not in a hurry and it needs to be done right |
20:18:44 | Llorean | kugel: Prejudice requires one not be aware of the facts. |
20:18:51 | pondlife | kugel: It's entirely a matter of opinion. Personally, I dislike ClearType, is that AAF? |
20:19:05 | pixelma | pondlife: it really seems to be related to shuffle |
20:19:06 | Llorean | 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 | pixelma | pondlife: or a shuffled playlist |
20:19:30 | Llorean | pondlife: AAF is a cheap and dirty thing in the general category of cleartype (which honestly looks MUCH nicer) |
20:19:31 | kugel | 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 | Llorean | kugel: We're forced to give up our RAM and binsize for it. |
20:19:46 | pondlife | I prefer the clear edges, no blurring. |
20:20:21 | pixelma | pondlife: what's really weird - is that not everything looks wrong (at least for me) |
20:20:40 | Llorean | kugel: Honestly, if you have no interest in attempting to improve the patch, just say so. |
20:21:11 | kugel | Llorean: I have, but not if I know there's nothing gonna happen until multifont |
20:21:48 | Llorean | 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 | Llorean | 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 | kugel | How? How can I show it won't conflict with something not existing? |
20:22:43 | Llorean | Well, you're the one who said it won't. |
20:22:52 | Llorean | I assumed you at least had some convincing argument to back up that assertion. |
20:22:55 | kugel | I said it *should* |
20:22:59 | kugel | should not rather |
20:23:10 | Llorean | But you have no reasoning for this? |
20:23:59 | Llorean | 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 | Llorean | 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 | kugel | Llorean: I had my reasoning, and you read it. I can't have any other reasoning, since multifont doesn't exist |
20:25:09 | Llorean | 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 | kugel | What makes you think you can only have 1 of them? |
20:25:50 | Llorean | kugel: See the key word IF |
20:25:57 | kugel | 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 | Llorean | 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 | linuxstb | 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 | domonoky | the only real way to know is to let time tell, and fix the conflicts when we know them.. |
20:26:52 | kugel | 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 | domonoky | 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 | linuxstb | 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 | Llorean | 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 | Llorean | 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 | domonoky | 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 | linuxstb | 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 | domonoky | 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 | domonoky | 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 | linuxstb | As I said, we can just restrict access "socially", rather than technically. |
20:35:05 | gevaerts | 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 | linuxstb | 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 | gevaerts | 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 | linuxstb | 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 | domonoky | 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 | domonoky | 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 | gevaerts | domonoky: the end of the week == tomorrow ? |
20:38:41 | pondlife | 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 | domonoky | his deadline is saturday midnight... so i have to last day to write his review.. |
20:39:21 | domonoky | yes, that was one of the intended things, be forced to talk to other rockbox devs to solve the svn thing.. |
20:39:44 | pondlife | i.e. the requirement boils down to him have a patch which is good enough to commit...? |
20:40:04 | linuxstb | domonoky: Ah, you're also talking about his technical problems accessing the Rockbox SVN server? |
20:40:24 | domonoky | linuxstb: thats another intended thing... :-) |
20:41:39 | linuxstb | 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 | domonoky | 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 | domonoky | 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 | Llorean | domonoky: Is the WPS preview realtime or via a "preview" or "update" button? |
20:45:14 | domonoky | 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 | linuxstb | Does it use the core code to display the WPS, or has it been re-implemented? |
20:46:39 | domonoky | thats rockbox code.. |
20:46:53 | domonoky | 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 | domonoky | :-) |
20:53:12 | | Quit Thundercloud_ (Read error: 110 (Connection timed out)) |
20:59:58 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
21:00 |
21:04:16 | | Join krz [0] (n=irc_by@turbo.sml.by) |
21:04:31 | | Part J-23 |
21:06:43 | domonoky | krz: so your svn problems are solved ? |
21:06:54 | krz | yes :) |
21:06:58 | krz | i hope |
21:07:14 | krz | for a long period of time, may be forever |
21:07:18 | domonoky | good... |
21:08:17 | domonoky | so now the question is, how to get your code into svn... |
21:08:56 | krz | we have a patch.. |
21:09:41 | domonoky | 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 | krz | 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 | krz | hm, may be co-mentor? i've never asked him before.. :) |
21:12:40 | domonoky | why not... |
21:13:11 | domonoky | or some other devs here like gevaerts or linuxstb or others... |
21:13:38 | krz | so, any volunteer? |
21:13:42 | krz | :) |
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 | domonoky | 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 | bertrik | bluebrother, I think it was needed for a fix :) |
21:18:07 | bluebrother | bertrik: noticed that. Should've dome that simply myself :) |
21:18:16 | kugel | 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 | krz | gevaerts: could you be a volunteer? |
21:18:26 | bluebrother | 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 | kugel | krz: Why is this anyway? |
21:20:09 | domonoky | jup, a all target editor would be nice, but i want it in svn before his deadline saturday midnight... |
21:20:32 | bluebrother | why that? Does the deadline require the code to be in svn? |
21:21:07 | domonoky | google doesnt require this, but i do.. :-) |
21:21:28 | bluebrother | 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 | domonoky | 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 | domonoky | 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 | bluebrother | well, I don't think it would rot in the tracker ... |
21:24:48 | domonoky | and its not like i said this to him earlier.. he knows this for quite some time.. |
21:25:13 | domonoky | so its one of the requirements i have, to let him pass... |
21:25:34 | bluebrother | your requirements to have him pass is you doing work? ;-) |
21:26:04 | | Quit Horscht ("electromagnetic radiation from satellite debris") |
21:26:06 | domonoky | 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 | domonoky | only if all fails, i will commit myself... |
21:27:18 | bluebrother | well, from now until saturday isn't quite long, especially if one wants to review the complete code |
21:27:43 | bluebrother | and I'm really against some namings −− like "proxy". |
21:28:08 | krz | so, what name would be better? |
21:28:24 | bluebrother | well, maybe something like "libwps"? |
21:28:44 | bluebrother | proxy could be anything. We have a proxy setting in rbutil for example, which is completely different |
21:29:30 | krz | ok |
21:29:36 | bluebrother | same for "gui". gui what? Could be anything too |
21:30:05 | krz | any proposes? |
21:30:24 | kugel | app |
21:30:32 | bluebrother | kugel: as bad as gui |
21:30:46 | bluebrother | well, why not call it "wpseditor"? At least that's what it is. |
21:30:52 | kugel | 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 | bluebrother | 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 | domonoky | so proxy should be changed but gui ? |
21:32:11 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
21:32:47 | kugel | krz: Would be nice if you answer my question |
21:33:05 | | Part fragilematter |
21:33:07 | bluebrother | 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 | krz | kugel: what question? |
21:33:29 | * | bluebrother didn't notice a question of kugel too |
21:33:41 | kugel | kugel>krz: Why is this anyway? |
21:34:09 | kugel | referring to the flaw I told linuxstb |
21:34:20 | krz | kugel: i can't answer to you right now |
21:35:16 | Lear | Hm, when I log out of flyspray nowdays, I get a blank page... Refresh doesn't help. |
21:35:30 | bluebrother | 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 | kugel | krz: ?? Why can't you answer? It's your software? |
21:40:01 | domonoky | kugel: you mean why it only shows the dimensions of the only target it supports at moment ? |
21:40:34 | kugel | yes |
21:41:21 | kugel | 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 | krz | 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 | linuxstb | Why is the wpseditor under rbutil/ ? It's not part of rbutil... |
21:42:54 | krz | linuxstb: it could be a part potentially |
21:43:00 | bluebrother | maybe rename the rbutil folder? It also holds ipodpatcher and sansapatcher |
21:43:15 | linuxstb | It holds ipodpatcher and sansapatcher because they're part of rbutil... |
21:43:18 | kugel | and checkwps |
21:43:21 | kugel | oops |
21:44:03 | kugel | 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 | linuxstb | 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 | bluebrother | we currently have tools and utils. hmm. |
21:48:31 | gevaerts | 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 | krz | 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 | krz | gevaerts: jup |
21:51:52 | gevaerts | 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 | domonoky | linuxstb: i think that should be solved with the different libs... there will be surely some problems, but it should work.. :-) |
21:53:03 | gevaerts | krz: I'll basically be available from 17:00 UTC to <late>. I can probably find some time earlier to already look at things, but not to really work on it |
21:53:41 | krz | gevaerts: i'll be from 14 UTC |
21:54:00 | Slasheri | reacocard: hi! sorry about not answering your mail yet, have been so busy at work.. :/ but trying to answer soon |
21:54:17 | Slasheri | reacocard: and update the wiki more |
21:54:31 | krz | 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 | Slasheri | 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 | Slasheri | reacocard: 2) it was just a type |
21:56:02 | Slasheri | *typo |
21:56:12 | gevaerts | 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 | Slasheri | 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 | gevaerts | 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 | Slasheri | 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 | krz | gevaerts: oki :) |
21:58:34 | reacocard | Slasheri: alright, thanks for the info. |
21:58:45 | Slasheri | 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 | reacocard | ah |
21:59:07 | gevaerts | 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 |
22:00:02 | krz | gevaerts: hope too |
22:00:11 | Slasheri | 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 | Slasheri | so the code operating with db should be able to handle both little endian and big endian |
22:00:47 | reacocard | Slasheri: well as Im reading straight from the disk files I have to wrroy about the endianness |
22:00:52 | domonoky | 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 | reacocard | Im nto using the existing code |
22:01:06 | gevaerts | domonoky: does that work for shared libraries? |
22:01:10 | amiconn | Slasheri: Endianless? Iiuc the db can handle both endianesses, but the native endianess of the respective target should be faster |
22:01:11 | Slasheri | reacocard: yes you need to worry about that if reading the db from player.. |
22:01:22 | Slasheri | iriver's have big endian, while ipods are little endian |
22:01:26 | | Quit ompaul (Client Quit) |
22:01:37 | Slasheri | amiconn: yes, that is what i meant |
22:01:49 | domonoky | it should, the resourcefile is for qt like another filesystem.. if not, you could copy them to temp while running.. |
22:01:51 | Slasheri | db uses always native endian but can handle both |
22:01:53 | bluebrother | 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 | amiconn | Slasheri: Btw, will we see a fix for fs #9093? |
22:02:09 | Slasheri | amiconn: i will check |
22:02:26 | bluebrother | 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 | reacocard | 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 | gevaerts | 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 | Slasheri | iirc, archoses _might_ be big endian also |
22:02:49 | amiconn | reacocard: All coldfire and SH1 targets are big endian |
22:02:54 | gevaerts | bluebrother: it still does, but at least it's known why |
22:03:00 | reacocard | thanks amiconn |
22:03:08 | domonoky | jup, the lib thing can come later. |
22:03:14 | amiconn | All current arm targets are little endian |
22:03:23 | * | gevaerts would like to see that fixed |
22:03:34 | bluebrother | 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 | Slasheri | amiconn: ah, that old bug.. |
22:04:56 | amiconn | yep :/ |
22:05:23 | Slasheri | amiconn: sorry, really trying to fix that as the next thing when having time to code something |
22:06:00 | gevaerts | 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 | reacocard | 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 | gevaerts | Actually, 7zip compresses 11 libs down to 80k |
22:08:02 | bluebrother | unfortunately you can't upx libraries ... |
22:08:03 | Slasheri | 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 | bluebrother | it does, at least for binaries. But it also depends on the debug infos |
22:08:54 | reacocard | 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 | krz | so, it can be even less |
22:09:14 | Slasheri | 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 | Slasheri | reacocard: yes |
22:09:26 | reacocard | ok |
22:09:31 | gevaerts | krz: this was without debug info |
22:10:24 | krz | ah |
22:10:43 | reacocard | 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 | Slasheri | reacocard: probably yes, at least i have yet no idea how to use the resurrected flag |
22:11:25 | reacocard | heh |
22:11:30 | reacocard | ok |
22:12:43 | Slasheri | at least it would be safe to remove the deleted entry in that case completely |
22:13:43 | Slasheri | 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 | Slasheri | so statistical data from deleted songs would also remain forever |
22:15:07 | reacocard | interesting idea |
22:15:50 | reacocard | 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 | Slasheri | 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 | reacocard | right but it doesnt reference it from the DB anymore so thats irrelevant |
22:17:01 | Slasheri | and after that information is lost, no resurrection is possible |
22:17:19 | reacocard | really? but its stores the crc32 in the old spot |
22:17:31 | reacocard | so you could take the new tag info, crc32 it and match it up |
22:17:32 | Slasheri | ah! indeed.. forget about that |
22:17:44 | Slasheri | you are correct.. hmm |
22:18:25 | reacocard | im pretty sure I saw code in tagcache.c that does exactly that |
22:18:35 | fml | 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 | bluebrother | fml: and only because I wanted to wait until 3.0 is ready :) |
22:20:30 | Slasheri | reacocard: ah, the FLAG_RESURRECTED was there to prevent processing the entry again |
22:21:14 | reacocard | Slasheri: ah, an "I already resurrected this" flag. so it shoudl stay in place until all matching deleted entries are removed. |
22:22:33 | Slasheri | indeed |
22:26:04 | --> | "delete quote dicks" received from PAKIRAQI (n=Tiki@pool-96-229-232-141.lsanca.fios.verizon.net) |
22:26:25 | reacocard | alright, ive condensed most of what we just talked about into the wiki page |
22:27:16 | reacocard | thanks for all the info, it'll e useful :D |
22:27:19 | reacocard | be* |
22:28:24 | | Quit krz ("чё за пургу вы тупые сучки несёте?") |
22:28:39 | | Quit Thundercloud (Read error: 110 (Connection timed out)) |
22:28:53 | Slasheri | reacocard: great :) |
22:29:19 | | Quit _hc () |
22:32:59 | | Join ^eRicSOn_Full^ [0] (n=ericson@124.104.71.170) |
22:33:04 | reacocard | 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 | Slasheri | 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 | Slasheri | it has nothing to do with dircache, just a way to prevent extra lookups to fetch that index id |
22:37:06 | Lear | reacocard: But a couple of crc32 functions (binascii and zlib modules)... |
22:37:15 | | Quit merbanan (Remote closed the connection) |
22:37:16 | reacocard | but once you're reading that entry dont you already know that index? or is this a different index? |
22:37:36 | reacocard | Lear: yeah I foudn one I can use in zlib. its not exposed in haslib as Id expect though. |
22:37:42 | reacocard | er, hashlib |
22:38:03 | Slasheri | reacocard: it's more complicated.. i don't remember the excact cause right now but we don't know it |
22:38:10 | reacocard | hrm |
22:38:10 | | Quit fml ("CGI:IRC (EOF)") |
22:38:21 | | Part Bensawsome ("The awsome is gone :(") |
22:38:40 | reacocard | btu its onyl set when dircache is enabled right? and thus only on the in-ram copy? |
22:38:51 | Slasheri | reacocard: or we know it but that information "gets lost" when building a lookup for data retrieval |
22:39:00 | Slasheri | indeed |
22:39:01 | Lear | reacocard: CRC isn't suitable for hashing, so no surprise there, really. (According to the binascii module.) :) |
22:39:17 | Slasheri | reacocard: i will check the exact use of that soon |
22:39:38 | reacocard | Lear: well, it is a HASH, so id expect it to be in there with a warning as to its ineffectiveness |
22:39:42 | reacocard | 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 | kugel | Slasheri: Ah hey |
22:46:03 | Slasheri | kugel: hi |
22:46:22 | kugel | any idea about the sort tags patch |
22:46:34 | Slasheri | reacocard: yep, get_next() needs that index id because there is no other way to get it when dircache is used |
22:46:40 | Slasheri | kugel: it looks good |
22:46:41 | kugel | 1 thing I didn't do is to bump the database version, but can that cause this? |
22:46:47 | Slasheri | kugel: but no idea why it causes issues |
22:46:53 | reacocard | Slasheri: ok, thanks |
22:47:07 | Slasheri | kugel: you must bump the version, or rebuild the db |
22:47:21 | kugel | Slasheri: I wonder if parsing the files created with reacocard/my own script reveals something. |
22:47:21 | Slasheri | if you have completely rebuild the db, it shouldn't be the issue |
22:47:30 | kugel | I did rebuild |
22:47:40 | Slasheri | then it shouldn't cause the problem |
22:47:41 | kugel | deleted tcc files |
22:47:45 | kugel | tcd* |
22:47:56 | reacocard | what patch is this? im curious |
22:48:10 | kugel | Slasheri: I've tried turning load to ram off, it didn't help |
22:48:17 | Slasheri | hmm, weird.. |
22:48:31 | Slasheri | kugel: it would be great to find the cause |
22:48:37 | kugel | 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 | kugel | reacocard: http://www.rockbox.org/tracker/task/7287 |
22:49:21 | kugel | v6 is acting weird |
22:50:05 | reacocard | oh interesting, I didnt even know about those tags. will have to look into this for Exaile |
22:50:45 | kugel | reacocard: those tags are quite useful imo |
22:50:52 | reacocard | yeah they would be |
22:51:07 | reacocard | 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 | kugel | 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 | Slasheri | hmm.. just found a little bug in tagcache that can cause some problems :) easy to fix |
22:53:18 | kugel | 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 | kugel | Slasheri: Yes? Where? |
22:54:19 | kugel | reacocard: If you do so, please save the initial database files, and those after corruption, and then compare both |
22:54:33 | kugel | Else I'll get my hands on it on the weekend |
22:54:37 | reacocard | 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 | kugel | ahh too bad |
22:55:15 | reacocard | sunday night is the earilest Ill have access to it |
22:55:19 | kugel | 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 | Slasheri | kugel: really no idea :/ |
22:57:30 | Slasheri | kugel: below the comment "Don't touch the dircache flag". That might destroy the entry index id from ram copy |
22:57:40 | Slasheri | will commit the fix tomorrow. after having tested it |
22:59:03 | kugel | Slasheri: Hopefully this is it |
22:59:33 | Slasheri | kugel: probably it wont help with your issue but could fix some tagcache weirdness |
22:59:55 | kugel | :( |
23:00 |
23:00:08 | Slasheri | well, of course it _might_ also fix your problem |
23:00:17 | Slasheri | and that would be awesome if it does! |
23:00:46 | Slasheri | 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 | Slasheri | well, it can't fix that unless you are using only the db in ram |
23:02:26 | kugel | Slasheri: that was one problem |
23:02:56 | Slasheri | ah, and the corruption.. |
23:03:11 | Slasheri | are you sure your FS/HDD isn't faulty? |
23:03:22 | Slasheri | tagcache fails very easily with a bad hdd |
23:03:38 | Slasheri | because it uses disk so intensively |
23:03:40 | kugel | The database is fine without the patch |
23:03:45 | Slasheri | interesting |
23:03:55 | Slasheri | oh.. just a moment! |
23:04:01 | Slasheri | now i see the issue |
23:04:56 | kugel | Slasheri: I've described the problems starting here: http://www.rockbox.org/irc/log-20080825#17:08:48 |
23:05:01 | Slasheri | kugel: you have added new string tags but forgot to update endian correction tables |
23:05:04 | Slasheri | that is the problem |
23:05:28 | kugel | ah |
23:05:29 | Slasheri | (see the very beginning of tagcache.c) |
23:05:32 | kugel | Yea, that's possible |
23:05:39 | Slasheri | that will almost certainly fix the problem |
23:06:11 | Slasheri | you need to add correct number of "l"'s to the table |
23:06:59 | kugel | static const char *index_entry_ec ? |
23:07:03 | Slasheri | yep |
23:07:09 | kugel | hm |
23:07:29 | Slasheri | that should contain TAG_COUNT +1 times the "l" |
23:07:34 | kugel | 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 | Slasheri | hmm.. you haven't incresed the TAG_COUNT either? |
23:08:19 | Slasheri | just wondering how it did work at all |
23:08:38 | kugel | hm |
23:08:45 | Slasheri | probably the define could be moved closer to the TAG_COUNT define |
23:09:16 | kugel | Well, I wasn't very much into tagcache (as I already mentioned). I thought/hoped the rest would be done automatically |
23:09:36 | Slasheri | kugel: you need to update TAG_COUNT (in tagcahce.h) and that endian table |
23:11:11 | kugel | couldn't tag_count be generated automatically? |
23:11:25 | kugel | BTW: haha I did actually bump the db version |
23:11:46 | Slasheri | it could, but probably it's simpler to do that way |
23:12:16 | kugel | there's this enum tag_type, why not just have TAG_COUNT after tag_mtime? |
23:12:18 | Slasheri | 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 | Slasheri | kugel: well, that is a good idea :) |
23:13:08 | kugel | Slasheri: :) |
23:13:20 | Zambezi | rasher: Translating 254 strings from English to Portugies could take approxiamly how long (if you know the language)? |
23:14:11 | rasher | Zambezi: no idea (and someone's already working on the portuguese translation - check the tracker) |
23:14:26 | kugel | Slasheri: why all the 1 in the endian correction? |
23:14:39 | reacocard | longs I think |
23:15:09 | kugel | ah yea, it's l, not 1 |
23:15:16 | kugel | stupid font |
23:15:22 | reacocard | heh |
23:15:24 | Zambezi | rasher: According to you homepage, last update is two years old. |
23:15:48 | reacocard | idk what font my gvim is using but it makes 1 and l look very different |
23:16:16 | rasher | Zambezi: http://www.rockbox.org/tracker/task/9238 |
23:16:45 | kugel | Slasheri: How about using snprintf(index_entry_ec, "l", TAG_COUNT+1); instead of *index_entry_ec = "lllllll[...]"; ? |
23:17:24 | Zambezi | rasher: Good it's in progress. I keep my eyes open for other needed people. |
23:17:25 | kugel | if that works |
23:17:27 | bluebrother | you could do that with memset too ... |
23:17:54 | kugel | anything is better than this declaration imho, since it's dependant on something |
23:17:58 | reacocard | kugel: well, what if you added a field that wasnt a long in the future? |
23:18:30 | kugel | 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 | bluebrother | s/static/const/ |
23:18:51 | reacocard | 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 | kugel | static const char *index_entry_ec |
23:19:10 | | Quit massiveH ("Leaving") |
23:19:23 | kugel | bluebrother: both even ;) |
23:20:16 | bluebrother | well, then your snprintf will create it in RAM, while it being const puts it into ROM. |
23:20:31 | kugel | anyway, declaring it like static const char *index_entry_ec[TAG_COUNT+1], and copy something in later should be fine |
23:20:38 | kugel | oh |
23:20:41 | bluebrother | doesn't make much of a difference for most targets but if you (can) flash your player (like h100) :) |
23:21:21 | bluebrother | or, to be more exact: const indicates it to be unmodifiable, which usually will put the string into ROM. |
23:21:56 | kugel | bluebrother: and you can't alter data in rom using a pointer? |
23:22:58 | Slasheri | kugel: well, it could be possible to preallocate and calculate the index_entry_ec during bootup |
23:23:18 | Slasheri | but no need to add too much complexity for these simple thing.. |
23:23:26 | Slasheri | programmer really has to understand doing these |
23:23:35 | kugel | Slasheri: Well, as of now, it's complex to add tags |
23:23:48 | Slasheri | no it's not |
23:23:51 | *** | Saving seen data "./dancer.seen" |
23:23:55 | Slasheri | once you know the internals.. |
23:24:00 | Slasheri | more comments would be ok |
23:24:10 | kugel | yea, indeed |
23:24:12 | reacocard | more comments are -always- a good idea |
23:24:18 | bluebrother | kugel: well, ROM means Read Only ... :D |
23:24:26 | reacocard | until you have more comments than code anyway :D |
23:25:01 | bluebrother | every code is complex if you don't know it. Except hello world maybe :) |
23:25:06 | Slasheri | kugel: you must have a basic understanding of a piece of code before doing something with it |
23:25:27 | Slasheri | no idea trying to automate everything |
23:25:49 | kugel | Slasheri: I have now! Also, I hoped someone would help me with it, but apparently noone came to that idea |
23:27:01 | kugel | Slasheri: I've even searched you for help, but you're unavailable at (many) times |
23:28:25 | kugel | And understanding tagcache really ain't easy |
23:30:57 | Slasheri | i dont doubt that.. tagcache is a very complex piece of code after all |
23:31:45 | | Quit jgarvey ("Leaving") |
23:32:17 | Nico_P | Slasheri: what kind of docs are there for it? |
23:32:42 | reacocard | 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 | kugel | reacocard: haha |
23:41:16 | kugel | 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 | robin0800 | 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 | kugel | 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)) |