| 00:05:05 | *** | Saving seen data "./dancer.seen" |
| 00:27:03 | | Quit GeekShadow (Quit: The cake is a lie !) |
| 00:27:54 | | Quit kevku (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/) |
| 00:45:45 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 00:53:49 | | Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110721152715]) |
| 00:56:25 | | Join hskf [0] (~hskf@32.162.148.192) |
| 01:00 |
| 01:02:39 | | Quit hskf (Quit: Bye) |
| 01:10:02 | | Quit pamaury (Remote host closed the connection) |
| 01:11:35 | | Quit sideral (Ping timeout: 240 seconds) |
| 01:15:14 | | Quit mudd1 (Quit: Ex-Chat) |
| 01:20:15 | | Quit robin0800 (Read error: Connection timed out) |
| 01:21:14 | | Join robin0800 [0] (~robin0800@149.254.60.165) |
| 01:21:19 | | Quit ender` (Quit: Just because I have a short attention span doesn't mean I) |
| 01:23:11 | | Join Strife1989 [0] (~Strife89@207-144-19-39.cstel.net) |
| 01:26:11 | | Quit bertrik (Read error: Connection timed out) |
| 01:26:48 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 01:26:49 | | Quit bertrik (Changing host) |
| 01:26:49 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 01:31:00 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 01:33:31 | | Join L-Strife89 [0] (~Strife89@207-144-19-39.cstel.net) |
| 01:33:49 | | Quit bertrik (Quit: :tiuQ) |
| 01:37:09 | | Quit Strife1989 (Ping timeout: 240 seconds) |
| 01:39:25 | | Join Ruffbad [0] (~d06128a2@giant.haxx.se) |
| 01:39:42 | Ruffbad | Hi |
| 01:40:44 | Ruffbad | is anyone on this irc? |
| 01:42:30 | | Quit Ruffbad (Client Quit) |
| 01:43:25 | | Join webguest34 [0] (~d06128a2@giant.haxx.se) |
| 01:43:32 | webguest34 | Hello |
| 01:44:23 | | Quit webguest34 (Client Quit) |
| 01:48:17 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 02:00 |
| 02:05:07 | *** | Saving seen data "./dancer.seen" |
| 02:36:54 | | Quit TheLemonMan (Quit: .) |
| 02:40:02 | | Quit Thra11 (Quit: kthxbai) |
| 02:43:09 | | Quit sideral (Quit: Leaving.) |
| 02:44:06 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 02:47:40 | | Join krazykit [0] (~krazykit@206.183.185.8) |
| 03:00 |
| 03:03:39 | | Quit bieber (Ping timeout: 250 seconds) |
| 03:09:31 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
| 03:15:53 | | Quit bieber (Ping timeout: 252 seconds) |
| 03:17:56 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
| 03:56:21 | | Quit mshathlonxp (Ping timeout: 240 seconds) |
| 04:00 |
| 04:02:21 | | Quit funman (Quit: leaving) |
| 04:05:10 | *** | Saving seen data "./dancer.seen" |
| 04:05:56 | | Quit TheSeven (Disconnected by services) |
| 04:06:11 | | Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) |
| 04:14:28 | | Quit mc2739 (*.net *.split) |
| 04:14:28 | | Quit soap (*.net *.split) |
| 04:14:28 | | Quit Zambezi (*.net *.split) |
| 04:15:00 | | Quit keyb_gr (Ping timeout: 276 seconds) |
| 04:15:05 | | Quit [fred] (Quit: bye) |
| 04:15:16 | | Join keyb_gr_ [0] (~chatzilla@p4FF01D9B.dip.t-dialin.net) |
| 04:15:30 | | Nick keyb_gr_ is now known as keyb_gr (~chatzilla@p4FF01D9B.dip.t-dialin.net) |
| 04:16:27 | | Join [fred] [0] (fred@ircop.efnet.at) |
| 04:17:03 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 04:17:03 | | Join soap [0] (~soap@rockbox/staff/soap) |
| 04:17:03 | | Join Zambezi [0] (Zulu@80.67.9.2) |
| 04:36:12 | | Quit keyb_gr (Remote host closed the connection) |
| 04:37:05 | [Saint] | sideral: ping? |
| 04:37:50 | sideral | Hello Saint, you rang? |
| 04:39:35 | [Saint] | Yeah, hey...how can I add "Album Artist" to "Same As Current" in my tagnavi_custom? |
| 04:39:41 | [Saint] | http://pastebin.com/bkz1dPwU |
| 04:39:47 | [Saint] | that's it, if it helps. |
| 04:42:15 | [Saint] | It occured to me it was missing, and "artist" and "album artist" can be two completely different things...its not in the svn tagnavi file for "same as current" either, perhaps it should be? |
| 04:42:46 | sideral | Add a line similar to the one containing #artist#, but splice in #albumartist# |
| 04:43:30 | [Saint] | Oh, right...so just copy the artist line, replacing artist with albumartist where it occurs? |
| 04:43:47 | [Saint] | I didn't think it'd be that simple, the tagnavi syntax baffles me ;) |
| 04:44:03 | sideral | right :) |
| 04:44:27 | sideral | "Album artist" -> albumartist ? albumartist = "#albumartist#" -> title = "fmt_title" |
| 04:44:48 | [Saint] | Right, thanks. |
| 04:45:09 | [Saint] | (In case you haven't noticed, you're my "Database-goto-Guy" ;) |
| 04:45:19 | sideral | Don't be so shy, you've mastered the sendmail.cf^Wtheme language instead :) |
| 04:45:56 | [Saint] | It has also mastered me many a time too :P |
| 04:46:16 | sideral | :) |
| 04:50:28 | | Quit amiconn (Disconnected by services) |
| 04:50:30 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:50:34 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:50:58 | | Quit pixelma (Disconnected by services) |
| 04:51:00 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:51:02 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:58:29 | | Quit sideral (Quit: Leaving.) |
| 05:00 |
| 05:10:21 | | Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) |
| 05:13:29 | | Join [Saint] [0] (~Saint]@124-197-58-10.callplus.net.nz) |
| 05:22:25 | | Join Llorean1 [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) |
| 05:22:36 | | Join Taco_Princess [0] (~Taco_Prin@unaffiliated/gamefreak264) |
| 05:24:59 | | Quit Llorean (Ping timeout: 260 seconds) |
| 05:44:07 | | Join Rob2223 [0] (~Miranda@p4FFF0BD0.dip.t-dialin.net) |
| 05:44:22 | | Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 05:48:30 | | Quit Rob2222 (Ping timeout: 260 seconds) |
| 06:00 |
| 06:05:13 | *** | Saving seen data "./dancer.seen" |
| 06:07:57 | | Quit [Saint] (Ping timeout: 264 seconds) |
| 06:20:29 | | Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) |
| 06:20:41 | | Join [Saint] [0] (~Saint]@124-197-58-10.callplus.net.nz) |
| 06:31:25 | | Join Horschti [0] (~Horscht@xbmc/user/horscht) |
| 06:33:13 | | Quit neferty (Ping timeout: 252 seconds) |
| 06:33:52 | | Quit robin0800 (Quit: Leaving) |
| 06:34:45 | | Quit Horscht (Ping timeout: 250 seconds) |
| 06:34:57 | | Join neferty [0] (~andor@173.242.127.201) |
| 06:40:10 | | Quit krnlyng (Ping timeout: 258 seconds) |
| 06:49:25 | | Quit [Saint] (Remote host closed the connection) |
| 06:50:56 | | Join [Saint] [0] (~st.lasciv@124-197-58-10.callplus.net.nz) |
| 07:00 |
| 07:15:54 | | Quit ReimuHakurei (Read error: Connection reset by peer) |
| 07:16:17 | | Join ReimuHakurei [0] (~kudo@wireless.sit-co.net) |
| 07:39:46 | | Join mystica555_ [0] (~mike@static-173-210-70-210.ngn.onecommunications.net) |
| 07:49:17 | | Quit L-Strife89 (Ping timeout: 250 seconds) |
| 07:50:19 | | Join ReimuHakurei_ [0] (~kudo@wireless.sit-co.net) |
| 07:52:09 | | Quit ReimuHakurei (Ping timeout: 240 seconds) |
| 08:00 |
| 08:05:17 | *** | Saving seen data "./dancer.seen" |
| 08:40:34 | | Join Topy [0] (~Topy44@g228227188.adsl.alicedsl.de) |
| 08:42:05 | | Quit Taco_Princess (Ping timeout: 240 seconds) |
| 08:44:07 | | Quit T44 (Ping timeout: 255 seconds) |
| 09:00 |
| 09:08:22 | | Join stoffel [0] (~quassel@p57B4B0FD.dip.t-dialin.net) |
| 09:09:04 | | Quit stoffel (Remote host closed the connection) |
| 09:09:37 | | Join stoffel [0] (~quassel@p57B4B0FD.dip.t-dialin.net) |
| 09:17:13 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 09:29:00 | | Quit sasquatch (Quit: WeeChat 0.3.5) |
| 09:29:27 | | Join sasquatch [0] (~username@p4FF2DB21.dip.t-dialin.net) |
| 09:34:59 | | Quit shai (Quit: Leaving) |
| 09:40:09 | | Quit simonlnu (Ping timeout: 258 seconds) |
| 09:42:37 | | Nick Llorean1 is now known as Llorean (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) |
| 09:42:41 | | Quit Llorean (Changing host) |
| 09:42:42 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 09:53:25 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 09:54:37 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 09:54:39 | | Quit bertrik (Changing host) |
| 09:54:39 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 10:00 |
| 10:03:04 | | Quit bluebrother (Disconnected by services) |
| 10:03:06 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
| 10:03:56 | | Join lasser [0] (~chatzilla@p57B58DDA.dip0.t-ipconnect.de) |
| 10:05:07 | | Quit fs-bluebot (Ping timeout: 255 seconds) |
| 10:05:20 | *** | Saving seen data "./dancer.seen" |
| 10:06:18 | | Join fs-bluebot [0] (~fs-bluebo@g226071021.adsl.alicedsl.de) |
| 10:10:23 | bluebroth3r | forum admins: MyJuliet seems to be sig-spamming. Removed some posts that were unrelated to the threads posted in. |
| 10:14:53 | JdGordon | banned |
| 10:32:12 | | Quit Horschti (Quit: Verlassend) |
| 10:34:16 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 10:39:41 | | Join Horscht [0] (~Horscht@p57B57A6A.dip.t-dialin.net) |
| 10:39:41 | | Quit Horscht (Changing host) |
| 10:39:41 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 10:50:06 | | Quit parafin (Quit: So long and thanks for all the fish) |
| 10:54:33 | | Join pamaury [0] (~quassel@cez63-2-88-164-98-172.fbx.proxad.net) |
| 10:54:38 | | Quit pamaury (Changing host) |
| 10:54:38 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 10:56:24 | | Quit user890104 (Ping timeout: 255 seconds) |
| 11:00 |
| 11:05:16 | | Join user890104 [0] (~Venci@213.226.63.145) |
| 11:30:42 | | Quit lasser (Quit: ChatZilla 0.9.87 [Iceweasel 3.5.16/20110701113851]) |
| 11:31:48 | * | user890104 found a bug in the forums: http://i.imgur.com/o0JNU.png |
| 11:34:37 | bertrik | I guess something like that could happen if a post is deleted (e.g. because of spam) |
| 11:35:00 | | Join TheLemonMan [0] (~lem0n@ppp-5-15.26-151.libero.it) |
| 11:35:44 | sideral | that's right, the last posting in this forum was a spam post |
| 11:36:00 | sideral | (according to the RSS feed) |
| 11:40:56 | | Quit stoffel (Ping timeout: 246 seconds) |
| 11:44:40 | bertrik | I'd like to get all of the model specific info of the AMSv2 players on one debug screen, so it becomes easier to relate weird stuff (like background noise) to a specific sub-model |
| 11:45:27 | bertrik | The clip+ for example has three things that can vary: 1) the display type 2) the radio chip 3) the wiring of the sd card |
| 11:45:47 | bertrik | I'm wondering about a clean way of doing this. |
| 11:46:10 | bertrik | The current way seems to be to just have a global variable for each variant. |
| 11:47:02 | pamaury | what do you propose instead of a global variable ? |
| 11:47:41 | pamaury | a global function returning the variant for each field ? |
| 11:48:01 | bertrik | not sure yet, maybe a system wide struct, to which you can get a pointer to read/modify things |
| 11:49:45 | pamaury | I think I would prefer some functions: int target_get_variant(int var); void target_set_variant(int var); but this won't change the face of the world |
| 11:50:16 | | Quit Xerion (Quit: ) |
| 11:50:45 | bertrik | pamaury, where var is a bitmap of various sub-model specific things or something similar? |
| 11:52:26 | pamaury | no a bitmap, just a number. Perhaps this would be cleaner: int target_get_variant(enum variant_t v) |
| 11:52:37 | pamaury | so you can do target_get_variant(LCD_TYPE); |
| 11:53:01 | pamaury | and target_set_variant(LCD_TYPE, SUPER_XVGA_4096x4096_LCD); |
| 11:53:15 | pamaury | :) |
| 11:53:39 | bertrik | like a (key,value) kind of thing |
| 11:53:42 | | Join stoffel [0] (~quassel@p57B4B0FD.dip.t-dialin.net) |
| 11:53:43 | pamaury | yes. |
| 11:54:32 | pamaury | But you can also do it with a bitmap if there aren't too many variant, like target_get_variant_bm(LCD_TYPE|SD_WIRING) == LCD_TYPE_1 | SD_WIRE_GPA |
| 11:54:59 | pamaury | in which case the function pretty much only AND the bitmap with the argument |
| 12:00 |
| 12:05:21 | *** | Saving seen data "./dancer.seen" |
| 12:06:53 | | Join user890104_ [0] (~Venci@83.228.31.135) |
| 12:07:16 | | Quit user890104 (Disconnected by services) |
| 12:07:26 | | Nick user890104_ is now known as user890104 (~Venci@83.228.31.135) |
| 12:21:19 | | Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) |
| 12:40:35 | | Quit antil33t () |
| 12:52:14 | | Join timccc [0] (~aoeu@112.166.15.141) |
| 12:55:20 | | Nick timccc is now known as user829385 (~aoeu@112.166.15.141) |
| 13:00 |
| 13:03:40 | | Quit mystica555_ (Ping timeout: 258 seconds) |
| 13:17:11 | | Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) |
| 13:27:54 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 13:40:18 | bertrik | pamaury, I'll think of something, maybe something as simple as just keeping the current global amsv2_variant global variable and use it as a bit map |
| 13:41:22 | pamaury | that's another possibility but there might be other targets with other variants, so having a general mechanism can be useful |
| 13:42:57 | pamaury | you can always use a functional interface which is implemented with macros and that's cleaner no ? |
| 13:52:45 | | Join Thra11 [0] (~thrall@195.73.113.87.dyn.plus.net) |
| 13:55:34 | | Quit Horscht (Quit: Verlassend) |
| 13:55:55 | | Quit Thra11 (Remote host closed the connection) |
| 13:55:59 | | Quit sideral (Quit: Leaving.) |
| 13:59:05 | | Join Thra11 [0] (~thrall@195.73.113.87.dyn.plus.net) |
| 13:59:35 | | Join Horscht [0] (~Horscht@p57B57A6A.dip.t-dialin.net) |
| 13:59:40 | | Quit Horscht (Changing host) |
| 13:59:40 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 14:00 |
| 14:05:22 | *** | Saving seen data "./dancer.seen" |
| 14:05:48 | | Quit TheLemonMan (Quit: .) |
| 14:06:15 | | Join TheLemonMan [0] (~lem0n@ppp-5-15.26-151.libero.it) |
| 14:07:09 | | Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) |
| 14:16:36 | | Join Horschti [0] (~Horscht@xbmc/user/horscht) |
| 14:18:25 | | Quit Horscht (Ping timeout: 258 seconds) |
| 14:26:49 | | Join y4n [0] (y4n@unaffiliated/y4ndexx) |
| 14:32:05 | bertrik | funny idea, it looks like the button light can be dimmed on the sansa fuze v2, variant 1. We could dim it in sync with the lcd backlight. |
| 14:35:24 | pamaury | yeah that would be funny, but not all people would like it I guess |
| 14:41:57 | | Quit stoffel (Ping timeout: 252 seconds) |
| 15:00 |
| 15:00:20 | * | bertrik wonders whose bright idea it was to share the HOME button with the I2C SCL line for communication with the tuner chip |
| 15:00:31 | bertrik | (on the fuze v2) |
| 15:04:01 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 15:06:40 | pamaury | were there lacking I/O pins up to this point ? |
| 15:06:44 | pamaury | *they |
| 15:08:05 | bertrik | Doesn't look like it |
| 15:12:35 | [Saint] | Does FuzeV2 have backlight fading? |
| 15:12:43 | [Saint] | I forget, mine doesn't have an LCD ;) |
| 15:13:02 | [Saint] | It'd be cool to fade the bottunlight with the LCD on screen on/off |
| 15:13:09 | [Saint] | *buttonlight too |
| 15:14:05 | | Join Poodlemastah [0] (~chatzilla@h-241-205.a218.priv.bahnhof.se) |
| 15:14:25 | | Quit Poodlemastah (Client Quit) |
| 15:15:14 | | Join FoH [0] (~foh@adsl-98-83-47-209.bhm.bellsouth.net) |
| 15:25:59 | | Join fdinel [0] (~Miranda@modemcable036.124-131-66.mc.videotron.ca) |
| 15:36:45 | | Quit bertrik (Read error: Connection timed out) |
| 15:37:27 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 15:37:27 | | Quit bertrik (Changing host) |
| 15:37:27 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 15:47:19 | | Join Thra11_ [0] (~thrall@91.125.76.254) |
| 15:49:35 | | Join GigaBrick [0] (~sagacious@67-5-112-12.spok.qwest.net) |
| 15:50:09 | | Quit Thra11 (Ping timeout: 252 seconds) |
| 15:50:43 | GigaBrick | Hey, guys, two quick questions... 1. Is it possible to calculate current battery capacity on an old battery using the figures from battery_bench and 2. Is it still possible to enter a custom figure for the "Battery Capacity" setting to get accurate runtime estimation? In regards to question 2, it seems that my player is locked on 830 mAh, but I remember on Rockbox v 3.0 being able to change it. |
| 15:52:19 | [Saint] | Settings - General Settings - System - Battery - Battery Capacity |
| 15:52:48 | [Saint] | if you need a higher value than it offers, you'll need to edit the source and compile your own build. |
| 15:53:13 | GigaBrick | Oh, so it's no longer a custom-entered figure? |
| 15:53:24 | [Saint] | It never has been afaik |
| 15:53:50 | bertrik | GigaBrick, some players can measure the battery current directly. We could add this to battery_bench to make it possible to determine total battery charge lost/gained during playback/charging, but we don't have that yet. |
| 15:53:55 | GigaBrick | Hmm, I could swear it use to offer me a menu of capacity levels to choose from... I guess maybe I've just been pounding my head based on faulty memory |
| 15:54:15 | [Saint] | GigaBrick: We're on different pages here :-S |
| 15:54:22 | [Saint] | yes, its a list selection. |
| 15:54:37 | [Saint] | I thought you meant you could just add any old value by your owrding |
| 15:54:45 | [Saint] | *wording |
| 15:55:08 | GigaBrick | Well, no, what it's showing me is just a figure of 830 mAh, and where once I remembered hitting select and a list coming up, it doesn't bring it up any longer |
| 15:55:42 | [Saint] | Sounds busted.... |
| 15:56:08 | GigaBrick | Could it be because the battery? I think this one is pretty much on its last leg |
| 15:56:32 | [Saint] | No, its nothing to do with the battery. The battery doesn't care about that list really. ;) |
| 15:56:42 | [Saint] | Its just for runtime estimation. |
| 15:57:13 | GigaBrick | Oh yeah, so I guess that wouldn't make sense |
| 15:57:14 | GigaBrick | WEird |
| 15:57:34 | GigaBrick | Now that I really look at it, it occurs to me that the "list" is being brought up, it's just the only figure it's showing is 830 mAh |
| 15:57:38 | bertrik | the max battery capacity on the ipod nano 1g is 600 mAh, I wonder if there's a battery that even comes close to that (default capacity is 300 mAh) |
| 15:58:03 | [Saint] | I guess its either a: broken, and no one has noticed it yet, or b: was removed for some reason deliberately. |
| 15:58:38 | GigaBrick | Hmm... Well, I guess it doesn't really matter too much, I just had the idea that maybe I could figure out what my dying-battery's current capacity is, change it, and have accurate runtime |
| 15:58:43 | bertrik | Should be configurable from 700 mAh to 1200 mAh, according to the source code |
| 15:58:48 | GigaBrick | But I think I'm probably going to be replacing the battery soon enough to disregard it completely |
| 15:58:59 | [Saint] | GigaBrick: That definitely sounds broken, update your build to current svn and see if you can reproduce it, and if you can, file a bug. |
| 15:59:04 | | Join Thra11__ [0] (~thrall@91.125.76.254) |
| 15:59:20 | GigaBrick | Okay, [Saint]. I just updated to the SVN two days ago though |
| 15:59:27 | | Nick Thra11__ is now known as Thra11 (~thrall@91.125.76.254) |
| 15:59:30 | GigaBrick | SHould I still go ahead and update it again? |
| 15:59:35 | [Saint] | yeah, bug reports need to be off current svn |
| 15:59:39 | GigaBrick | k |
| 15:59:49 | [Saint] | in case it fixed itself and you end up wasting someones time ;) |
| 15:59:56 | GigaBrick | Heh, good point |
| 16:00 |
| 16:00:30 | [Saint] | It also makes sure that nothing messed up during your installation, so...its just "A good thing to do". |
| 16:01:18 | | Quit Thra11_ (Ping timeout: 240 seconds) |
| 16:02:26 | GigaBrick | Installing through the RbUtil is pretty much the same as a "clean install" too? Just to make sure I"m not leaving some things behind or anything... |
| 16:02:44 | GigaBrick | Using "clean install" for lack of a better term... |
| 16:04:50 | | Join mystica555_ [0] (~mike@static-173-210-70-210.ngn.onecommunications.net) |
| 16:04:51 | bertrik | GigaBrick, What target do you have exactly (I was assuming the gigabeat s) |
| 16:04:59 | GigaBrick | Gigabeat F40 |
| 16:05:23 | *** | Saving seen data "./dancer.seen" |
| 16:05:38 | | Join ender` [0] (~ender@foo.eternallybored.org) |
| 16:06:12 | bertrik | hm, ok that one is fixed to 830 mAh, but could easily be changed to allow a list of capacities |
| 16:06:50 | GigaBrick | Custom compilation? |
| 16:07:42 | bertrik | yes, the source code will have to be modified for that |
| 16:07:48 | [Saint] | It would require that at this point, yes. |
| 16:08:01 | [Saint] | Is there any reason to not have this in svn though? |
| 16:08:05 | [Saint] | was it removed? |
| 16:08:22 | bertrik | It was last changed in april 2009, probably not removed |
| 16:09:42 | bertrik | Before that, it could be changed, but the capacity range was completely wrong (1500-2500 mAh) |
| 16:10:11 | [Saint] | that seems to make some sense...before 3.9 this user was running 3.0 iirc |
| 16:10:22 | GigaBrick | Yep |
| 16:10:34 | GigaBrick | I was going to say I think I remember it being that way in the 3.9 release build too |
| 16:11:03 | [Saint] | No, it definitely wasn't. If it was last touched in '09 ;) |
| 16:12:13 | GigaBrick | No, I meant I think it was fixed to 830 in the relase build. Can't remember though, I was only on that one for a few days before updating to SVN |
| 16:12:54 | GigaBrick | I like the new playlist handling btw :P |
| 16:14:28 | [Saint] | The author of the patch will be pleased. It was a long time coming. |
| 16:14:56 | | Quit Thra11 (Remote host closed the connection) |
| 16:16:07 | GigaBrick | Yeah, I kind of got use to just loading them up so it was a little confusing at first, but I like it better since I can review a playlist before loading it |
| 16:16:10 | [Saint] | You must have been quite impressed updating from 3.0 to 3.9, just don't expect as many new features get added when you update from 3.9 to 3.10 :P |
| 16:17:01 | GigaBrick | Heh, yeah, I don't think I'm going to wait quite as long either lol |
| 16:17:39 | GigaBrick | I think the compressor is my new favorite feature |
| 16:17:44 | GigaBrick | THough I guess it's probably not very new at this point |
| 16:17:51 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 16:23:27 | GigaBrick | So I was thinking about modifying my source for a bit of a custom build |
| 16:24:22 | GigaBrick | I need to get my feet wet in actually compiling a build first though |
| 16:24:38 | | Quit user829385 (Ping timeout: 276 seconds) |
| 16:25:07 | [Saint] | GigaBrick: http://www.rockbox.org/wiki/DevelopmentGuide |
| 16:25:32 | GigaBrick | Heh, yeah, I have that loaded in my tab right now. :P |
| 16:25:44 | [Saint] | Do *NOT* use CygWin... |
| 16:25:58 | GigaBrick | Heh, okay, I'll keep that in mind |
| 16:26:00 | [Saint] | (well, by all means do if you have endless time to waste ;)) |
| 16:26:07 | GigaBrick | Heh |
| 16:26:14 | GigaBrick | Nah, I'm on Ubuntu Linux |
| 16:26:20 | GigaBrick | Is there any GCC version requirement? |
| 16:26:44 | [Saint] | There is, but our toolchain script pulls everything it needs. |
| 16:27:08 | GigaBrick | Oh, okay, I think I might just use a virtualmachine like you guys suggest then |
| 16:27:25 | GigaBrick | I've been meaning to upgrade my gcc version forever, but I've got a bunch of depencies I've got to take care of |
| 16:27:33 | GigaBrick | *dependencies |
| 16:27:36 | [Saint] | It won't touch the system GCC |
| 16:28:04 | GigaBrick | Oh, well, seems I'll be good either way then. :D |
| 16:28:28 | GigaBrick | But, yeah, I'm pretty sure what I want to do is actually available in a patch, I just figured it'd be a good place to get started with modifying code |
| 16:28:40 | GigaBrick | I just want to get my playlist viewer to display the MP3 title tag instead of the filename |
| 16:28:54 | [Saint] | the Vm option is only "Strongly Recommended" for Windows development. |
| 16:28:56 | GigaBrick | No idea how much of a task that's going to be yet though, but should be fun. :P |
| 16:29:08 | [Saint] | on a linux distro it'd just add an irrelevant layer. |
| 16:30:14 | [Saint] | GigaBrick: the link you *actually* want then is: http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling |
| 16:30:16 | | Quit Horschti (Quit: Verlassend) |
| 16:30:49 | GigaBrick | Oh, nice, just the versions of ubuntu I like too |
| 16:31:03 | [Saint] | this will leave you (if all directions are folowed) with a fully operational development environment in ~6 hours with a reasonable connection. |
| 16:32:40 | [Saint] | Just remember to ignore the part about modifying the $PATH variable. |
| 16:32:50 | [Saint] | that is not needed and I will remove that from the wiki now. |
| 16:35:10 | GigaBrick | Okay, I'm pretty sure /usr/local/bin is in mine anyway |
| 16:35:20 | [Saint] | since <quite some time ago> the toolchains are now located in a directory that is already part of the default $PATH, so no need to worry about that. |
| 16:35:30 | GigaBrick | I've got a lot of custom built stuff... Tends to happen when you don't update your ubuntu version for three versions haha |
| 16:36:05 | GigaBrick | Okay, well either way I should be able to figure that stuff out, seems pretty straight forward |
| 16:36:09 | GigaBrick | The Ui Simulator looks pretty neat |
| 16:47:32 | kugel | gevaerts: I would perhaps like to commit the one buffer_get_buffer() patch |
| 16:48:46 | gevaerts | kugel: sounds like a sensible start |
| 16:49:44 | kugel | not sure if the other one is ready. there's still 1 or 2 target-specific buffer_allocs left, and no locking implemented (although locking isn't needed without compaction yet) |
| 16:50:45 | gevaerts | True, but I think implementing locking is a good way to validate APIs |
| 16:54:27 | | Join hskf [0] (~hskf@32.134.104.201) |
| 16:57:35 | gevaerts | Of course there's also the observation that people tend to only look at things when they're committed... |
| 17:00 |
| 17:06:30 | kugel | gevaerts: have you read my comment on the task? |
| 17:07:32 | gevaerts | Yes, I just read it |
| 17:07:57 | gevaerts | I think that's the simplest solution |
| 17:11:32 | kugel | perhaps not |
| 17:11:56 | kugel | scrobbler.c doesn't need any callbacks as such, but it does I/O with the buffer |
| 17:18:28 | kugel | so scrollber seems to need the callback just to be able to tell to not move right now |
| 17:19:43 | | Join Horscht [0] (~Horscht@p5DD57CD2.dip.t-dialin.net) |
| 17:19:43 | | Quit Horscht (Changing host) |
| 17:19:43 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 17:26:21 | gevaerts | true |
| 17:28:03 | | Quit mystica555_ (Ping timeout: 252 seconds) |
| 17:34:44 | gevaerts | There's actually another tradeoff that users have to make. If you have one (non-yielding, let's keep things simple) function that uses the buffer, retrieving the correct pointer at the start of the function is probably best. If on the other hand you have fifty-seven functions that need it, having a callback to maintain the pointer is going to be a lot less code. |
| 17:34:50 | gevaerts | hm |
| 17:35:22 | gevaerts | Didn't you say at some point that no callback meant no moving? Or do you mean scrobbler might use some default callback? |
| 17:36:42 | kugel | no callbacks means default callback, NULL callbacks means no move/shrink |
| 17:36:56 | gevaerts | right |
| 17:37:58 | kugel | i.e. core_alloc() or core_alloc_ex(..., NULL) is default callbacks, as opposed to core_alloc_ex(...,&ops) with ops = { NULL, NULL } which means don't move/shrink |
| 17:38:09 | | Join stoffel [0] (~quassel@p57B49D2F.dip.t-dialin.net) |
| 17:38:27 | gevaerts | Do you have some sort of idea about how many allocations there will be typically? |
| 17:38:50 | kugel | I think there are 15 or so currently |
| 17:40:40 | gevaerts | Ok. I suspect that that number will increase a bit over time (if there's an easy way to allocate memory, people will use it), but that still means the overhead of this locking bool is (worst case) no more than a few hundred bytes (assuming a major increase in allocations, and assuming padding constraints say you need four bytes) |
| 17:41:21 | | Quit robin0800 (Quit: Leaving) |
| 17:45:01 | kugel | I think I still prefer BUFLIB_CB_DEFER_MOVE |
| 17:45:10 | kugel | it's more in line with the shrink callback |
| 17:45:24 | gevaerts | Yes, I intuitively prefer it too |
| 17:46:37 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 17:53:11 | | Quit bertrik (Read error: Connection timed out) |
| 17:53:37 | | Quit hskf (Ping timeout: 240 seconds) |
| 17:53:44 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 18:00 |
| 18:04:49 | | Quit stoffel (Remote host closed the connection) |
| 18:05:26 | *** | Saving seen data "./dancer.seen" |
| 18:06:47 | | Join stoffel [0] (~quassel@p57B49D2F.dip.t-dialin.net) |
| 18:10:11 | | Quit GeekShadow (Ping timeout: 255 seconds) |
| 18:14:33 | | Join GeekShadow [0] (~Antoine@81.252.8.57) |
| 18:14:36 | | Quit GeekShadow (Changing host) |
| 18:14:36 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 18:19:59 | kugel | amiconn: svn crashes for me on hwcodec |
| 18:20:03 | kugel | in probe_file_format |
| 18:20:45 | sideral | kugel: My (probably dircache-related) problem of trash file and dir names persists despite my recent DB fixes |
| 18:21:04 | kugel | I thought that was fixed |
| 18:21:24 | sideral | I explicitly said I don't know yet :) |
| 18:22:02 | kugel | I thought r30122 fixed that |
| 18:22:26 | sideral | Unfortunately, it did not :( |
| 18:23:18 | sideral | The observation is that the DB update keeps scanning files forever (well, for a very long time), because multiple trash directories seem to contain the same contents |
| 18:23:57 | sideral | still haven't been able to reproduce this with a simulator |
| 18:24:39 | sideral | This is always with the rescan after a DB commit, so after the dircache has been reloaded |
| 18:25:41 | kugel | so without db there's no problem at all? |
| 18:26:19 | kugel | does the db reload the dircache indicies after the dircache is reloaded? |
| 18:26:23 | sideral | I always use the DB, so I don't know that. But apparently it does not occur if I don't add/remove files and there is no initial commit |
| 18:27:13 | sideral | you mean before/after the *tag*cache is reloaded? |
| 18:27:30 | kugel | no |
| 18:27:36 | kugel | dircache |
| 18:27:40 | sideral | after a commit, the DB first reloads the dircache, then the DB ram cache |
| 18:27:45 | kugel | e.g. after stealing the dircache buffer |
| 18:28:20 | sideral | and after that, another scan is triggered (likely for no good reason, but that's a different story ;) ) |
| 18:29:53 | kugel | so there's no visible corruption, just that the db scans forever? |
| 18:30:00 | sideral | if that doesn't that answer your question, I've probably misunderstood it. what is a dircache index? |
| 18:30:30 | kugel | the indicies returned by dircache_get_idx() |
| 18:30:53 | kugel | afaik they are cached by tagcache for filename tags |
| 18:31:38 | sideral | I don't know. The commit function calls dircache_build(0) to rebuild the dircache. Whatever that function does. |
| 18:31:55 | kugel | I mean does tagcache reload that cache |
| 18:32:04 | kugel | or discard |
| 18:32:05 | sideral | The corruption is visible −− both in the file browser and in the DB debug screen (which shows the currently scanned file name) |
| 18:32:25 | kugel | I don't see that on my e200 |
| 18:33:21 | sideral | kugel: After scan, and before commit, the dircache is released, and after commit, it's reloaded. Have a look at the tagcache.c:commit() function (look for #ifdef HAVE_DIRCACHE) |
| 18:33:49 | kugel | is there a way to trigger that corruption? |
| 18:34:00 | kugel | do I need some setting? I don't see it |
| 18:34:08 | | Quit FoH (Quit: Introducing X to a 'new' monitor.) |
| 18:34:20 | sideral | I have no reliable way to trigger it, but some of the ingredients are: |
| 18:34:29 | sideral | 1. DB auto update enabled |
| 18:34:33 | sideral | 2. dircache enabled |
| 18:34:50 | kugel | oh there is something |
| 18:34:53 | sideral | 3. remove and add some files in USB mode |
| 18:35:02 | sideral | 4. reboot to trigger autoupdate |
| 18:35:19 | kugel | I see an extra entry ".<some nonprintable char>" in each dir |
| 18:35:26 | sideral | that's it |
| 18:35:47 | sideral | how did you do it? |
| 18:36:27 | kugel | 1. init db, 2. reboot, 3. enable dircache, 4. reboot, 5. insert sd, 6. reboot |
| 18:36:36 | kugel | it seems to be the . entry |
| 18:37:34 | | Quit Strife89 (Read error: Connection reset by peer) |
| 18:37:40 | sideral | My guess is that it's related to the dircache reload, that is, whatever happens in dircache_build(0) |
| 18:39:40 | kugel | did you see other corruption or only this? |
| 18:40:13 | | Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) |
| 18:40:30 | sideral | I believe it's only this. The problem seems to be that entering that directory yields the same directory contents again, so scanning never finished. |
| 18:40:41 | sideral | That's consistent with your hypothesis that it's the "." entry |
| 18:40:58 | kugel | it looks like there's garbage after the . |
| 18:41:11 | kugel | probably making the strcmp(...,".") fail |
| 18:41:27 | sideral | yep |
| 18:41:49 | kugel | "." is at the very end of the dircache. perhaps some nasty thing overwrites the very last byte |
| 18:41:57 | kugel | which should be |
| 18:42:08 | kugel | \\0 |
| 18:42:40 | sideral | re your question on flushing the dircache indeces: I think I now understand the question. Of course, the entire DB (including all index refs) is flushed before it's reloaded |
| 18:43:15 | sideral | perhaps your calculation of where ".\0" gets put has an off-by-one error? |
| 18:43:31 | kugel | that's possible too |
| 18:43:50 | kugel | this does happen when the cache is *not* compacted, right? |
| 18:44:01 | kugel | (only the initial dircache scan compacts) |
| 18:44:03 | sideral | typically the DB is allocated immediately behind the dircache. when it gets reloaded, it overwrites the first few bytes (its ramcache_header) |
| 18:44:19 | sideral | I believe so |
| 18:45:15 | sideral | what does the trash look like? perhaps it's the ascii representation of a dircache header? :) |
| 18:45:27 | kugel | perhaps the db does alignment fixup wrongly? |
| 18:45:55 | kugel | like rounding down instead of up |
| 18:46:10 | sideral | that's of course possible. let me have a look |
| 18:46:46 | kugel | I see that the dircache does strcpy the "." entry, so it's having the 0 byte |
| 18:46:57 | kugel | something must be overwriting that 0 byte afterwards |
| 18:47:11 | sideral | but where to? maybe the target ptr is off by one? |
| 18:48:09 | kugel | before generate_dot_dnames(), d_names_start == d_names_end (pointing to the first byte after the cache) |
| 18:48:18 | sideral | the tagcache uses buffer_alloc to allocate the ram cache, which rounds up |
| 18:48:27 | kugel | then dot = d_names_start - 2 (for '.' and 0) |
| 18:49:15 | sideral | those entries are recreated every time the dircache is rebuild, right? |
| 18:49:18 | kugel | yes |
| 18:50:15 | | Join z180 [0] (~chatzilla@ip-2-202-230-152.web.vodafone.de) |
| 18:52:26 | z180 | you could try to find some of the DB related bugs via code checkers like clang or cpppcheck |
| 18:53:26 | sideral | kugel: Could you check whether you can reproduce the error with the simulator with the same steps? |
| 18:53:43 | kugel | does the sim have a sd? :( |
| 18:53:50 | sideral | the you could set a hardware breakpoint at the end of the dircache |
| 18:54:05 | sideral | kugel: yeah, simply add the files on your sim to your simdisk |
| 18:54:29 | sideral | s/sim/SD/ |
| 18:54:40 | z180 | does your sim bzero() out its RAM? |
| 18:55:22 | sideral | z180: not sure |
| 18:57:08 | | Part Toes ("Leaving") |
| 19:00 |
| 19:02:35 | sideral | kugel: when is the code path with the second if in dircache_build used? |
| 19:02:56 | pamaury | is there a #define in config file to rotate the screen (for target with a 240x320 screen which is meant to be used in rotated 320x240) |
| 19:02:57 | pamaury | ? |
| 19:03:36 | sideral | kugel: I'm wondering if the size calculation is that path is correct. It rounds up dircache_root, but doesn't decrease allocated_size accordingly |
| 19:04:49 | z180 | you talk about the nano 4g? |
| 19:05:55 | sideral | z180: me? no, clip+ |
| 19:09:07 | | Quit stripwax (Quit: http://miranda-im.org) |
| 19:11:36 | | Join mrkiko [0] (~mrkiko@host63-229-dynamic.58-82-r.retail.telecomitalia.it) |
| 19:11:54 | mrkiko | Hi all! I'm sorry - I know I should have checked in the site but... are some variants of samsung vibe (mp3 player) supported? |
| 19:14:17 | gevaerts | no |
| 19:15:39 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 19:15:46 | TheLemonMan | samsung vibe ? |
| 19:16:13 | | Quit Strife89 (Ping timeout: 250 seconds) |
| 19:17:35 | kugel | sideral: when the dircache size is known from the previous boot |
| 19:18:06 | kugel | that's the normal case I'd say |
| 19:18:39 | z180 | mrkiko look if someone has disassembled and what CPU is inside |
| 19:19:55 | z180 | sideral no i meant pamaury the clip+ has no 320 x 240 screen,if it has i would have rockboxed it |
| 19:21:39 | | Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) |
| 19:21:47 | sideral | kugel: Oh, then the missing allocated_size fixup might be the problem? |
| 19:22:37 | kugel | what do you mean? |
| 19:22:55 | kugel | ALIGN_BUFFER does that, no? |
| 19:23:09 | sideral | oh does it? darn :) |
| 19:23:43 | kugel | it rounds up the pounter and rounds down pointer+size |
| 19:24:41 | pamaury | z180: my comment was totally unrelated to anything in the chan :) |
| 19:25:04 | sideral | OK, good. I was wondering anyway why an error there would cause a reload to fail :) |
| 19:25:11 | sideral | kugel: ^ |
| 19:25:32 | kugel | the sim doesn't notice when I add files outside |
| 19:25:49 | sideral | do you have autoupdate enabled? |
| 19:26:04 | kugel | autoupdate is unrelated |
| 19:26:06 | sideral | and you need to restart the sim, of course :) |
| 19:26:11 | kugel | it doesn't notice because dircache is active |
| 19:26:47 | kugel | that doesn't expose the problem |
| 19:27:33 | sideral | huh? your recipe had a reboot there. |
| 19:28:09 | kugel | right |
| 19:28:21 | kugel | but it doesn't show the problem anyway :) |
| 19:28:34 | sideral | dang |
| 19:28:39 | pamaury | TheLemonMan: any progress with your port ? |
| 19:28:41 | kugel | toggling the SD seems to be enough on my e200 apparently |
| 19:28:58 | sideral | is the DB update involved at all on your e200? |
| 19:29:16 | TheLemonMan | the dma seems to work but the nand is stuck in WAITING_WRITE mode forever |
| 19:29:51 | pamaury | you can read from the nand ? |
| 19:30:06 | kugel | sideral: the show files setting seems to make a difference |
| 19:30:27 | kugel | sideral: don't know. it's initialized but I don't have autoupdate enabled |
| 19:30:32 | TheLemonMan | it's stuck when sending the command |
| 19:30:38 | sideral | ah, show files, obviously :) |
| 19:31:05 | kugel | the sim crashes if it's on |
| 19:31:09 | kugel | on show all |
| 19:31:14 | sideral | that's good! |
| 19:31:31 | sideral | now enter "gdb rockboxui" ;) |
| 19:32:52 | kugel | hm, dircache_gen_next() fails |
| 19:33:33 | kugel | no wait |
| 19:33:42 | * | sideral waits |
| 19:34:27 | kugel | http://pastie.org/2295297 |
| 19:34:32 | sideral | I suggest to set a write breakpoint at the \0 byte of the "." entry |
| 19:34:49 | kugel | the crash is a separate problem it seems |
| 19:35:14 | sideral | stack overflow due to nesting loop of "." entries? |
| 19:38:04 | kugel | I don't think the sim can stkov |
| 19:38:14 | sideral | print ce |
| 19:38:22 | kugel | oh well it can |
| 19:38:26 | kugel | since my threading rework |
| 19:38:32 | kugel | ce is NULL |
| 19:39:00 | kugel | but it's not clear whether the ce passed to sab_process_dir was also NULL (gdb says so, but I doubt it) |
| 19:39:03 | sideral | allocate_entry may have failed |
| 19:39:45 | sideral | I think you should try catching that ".\0" overwrite first |
| 19:40:22 | kugel | sideral: I need to get the sim to start up first :) |
| 19:40:27 | sideral | with a hardware watchpoint, enabled right after generate_dot_d_names |
| 19:40:58 | sideral | where you should set a breakpoint |
| 19:41:24 | sideral | you can set breakpoints before running the program |
| 19:41:52 | sideral | BTW, are you using an SDL-thread enabled sim? |
| 19:41:55 | kugel | no |
| 19:42:38 | kugel | ohh, the cache is now 4MB, there's clearly something wrong |
| 19:43:30 | sideral | that means its scan is recursing somewhere. probably that "." loop again |
| 19:44:01 | sideral | you really should set a breakpoint before it does that :) |
| 19:45:36 | sideral | kugel: will you be around later tonight? I'm taking a dinner break now |
| 19:47:18 | kugel | it looks like |
| 19:47:54 | sideral | :) OK, I'll catch up with you later then. Thanks for diving into this! |
| 19:49:12 | | Join timccc [0] (~aoeu@112.166.15.141) |
| 19:54:59 | z180 | do rockbox guys help reversing on freemyipod.org? |
| 19:57:57 | timccc | only the drunk ones |
| 19:58:06 | | Nick timccc is now known as user78200229 (~aoeu@112.166.15.141) |
| 19:58:15 | | Quit mc2739 (Ping timeout: 250 seconds) |
| 19:58:17 | | Join Horschti [0] (~Horscht@xbmc/user/horscht) |
| 19:59:42 | gevaerts | z180: rockbox and freemyipod have some people in common, if that's what you're asking |
| 19:59:43 | | Quit z180 (Quit: ChatZilla 0.9.87 [Firefox 3.6.18/20110614230723]) |
| 20:00 |
| 20:00:22 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 20:01:45 | kugel | sideral: I can't repo in the sim |
| 20:02:22 | | Quit Horscht (Ping timeout: 276 seconds) |
| 20:02:30 | sideral | kugel: oh? |
| 20:02:48 | kugel | my crash was the result of recursive symbolic links :) |
| 20:03:11 | sideral | but I thought you saw the corrupted dir entries in the sim? |
| 20:03:20 | kugel | no |
| 20:03:28 | | Join robin0800 [0] (~robin0800@genld-219-248.t-mobile.co.uk) |
| 20:04:14 | | Quit sideral (Remote host closed the connection) |
| 20:05:26 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 20:05:27 | *** | Saving seen data "./dancer.seen" |
| 20:07:00 | sideral | why would "show files" make any difference? |
| 20:07:31 | kugel | the corrupted entry is hidden |
| 20:07:54 | kugel | strange it's not reproducible with the sim |
| 20:09:25 | | Quit robin0800 (Ping timeout: 255 seconds) |
| 20:09:30 | kugel | oha |
| 20:09:33 | * | sideral is confused the entry corrupted by the recursive symlink? |
| 20:09:49 | kugel | d_names_end and dot/dotdot are completely differnet addresses |
| 20:10:00 | kugel | sideral: no the crash I had in the sim |
| 20:10:15 | kugel | I only had the corrupted entry on the e200 target |
| 20:10:20 | kugel | (still have) |
| 20:10:22 | | Quit stoffel (Ping timeout: 240 seconds) |
| 20:10:32 | | Nick user78200229 is now known as user829385 (~aoeu@112.166.15.141) |
| 20:11:37 | sideral | interesting! |
| 20:11:58 | kugel | meh, not anymore |
| 20:12:01 | | Quit sideral (Remote host closed the connection) |
| 20:12:24 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 20:12:28 | * | sideral can't keep his eyes off the screen despite it being dinner time |
| 20:13:53 | | Quit evilnick (Read error: Connection reset by peer) |
| 20:15:03 | kugel | hah! I think I have it |
| 20:15:12 | sideral | and? |
| 20:15:25 | kugel | dot and dotdot aren't update after compaction |
| 20:15:39 | sideral | oops |
| 20:15:49 | kugel | new entries (that go into the reserve buffer) get the old values |
| 20:18:53 | sideral | kugel: are you still sure you want to introduce movable allocations as part of your GSoC work? :) |
| 20:19:10 | kugel | I don't think I have much choice :) |
| 20:19:10 | sideral | To me it seems more and more clear that moving stuff around introduces complexity and hard to find bugs |
| 20:19:38 | sideral | Well, I outlined an alternative a few weeks ago |
| 20:20:51 | kugel | hm, the bug is still there |
| 20:22:16 | | Quit sideral (Remote host closed the connection) |
| 20:22:34 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 20:22:59 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 20:23:05 | sideral | do existing dircache entries also reference the old dotfile-name locations? |
| 20:23:25 | | Quit TheLemonMan (Quit: .) |
| 20:23:37 | kugel | n |
| 20:23:38 | kugel | no |
| 20:23:46 | kugel | they shouldnt :) |
| 20:24:55 | sideral | as the trash name appears in all directories, perhaps they actually do? |
| 20:25:20 | sideral | you should be able to check with the debugger... |
| 20:26:15 | kugel | sideral: I repeat once more: I don't see the corruption in the sim |
| 20:26:17 | | Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) |
| 20:27:08 | sideral | well, not on the screen. but you saw the ptr inconsistency in the sim, didn't you? |
| 20:28:10 | kugel | the entries point to the right thing |
| 20:28:25 | sideral | OK, that's what I was wondering |
| 20:29:02 | sideral | can you put up your patch (pastebin)? |
| 20:29:45 | kugel | http://pastie.org/2295462 |
| 20:30:12 | kugel | I'm now trying to replicate the e200 behavior in the sim by somehow posting a SYS_FS_CHANGED event |
| 20:30:33 | kugel | but somewhy I can't set up a signal handler |
| 20:32:31 | | Quit sideral (Remote host closed the connection) |
| 20:32:46 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 20:32:51 | sideral | perhaps the DB update route works for you as well? (quit, add files, restart, DB update) Like SYS_FS_CHANGED, it should cause a dircache reload |
| 20:33:56 | kugel | I tried that |
| 20:35:25 | kugel | meh, HOTSWAP isn't enabled in the sim |
| 20:37:33 | | Join robin0800 [0] (~robin0800@genld-217-248.t-mobile.co.uk) |
| 20:39:50 | | Quit piotrekm (Quit: piotrekm) |
| 20:41:24 | kugel | sideral: with usb simulation the dircache is also reloaded. but I still cannot manage to repro |
| 20:42:17 | sideral | what do the pointers look like in the sim after the dircache is reloaded? |
| 20:43:16 | sideral | I'm hypothesizing that you'll never see any corruption in the sim because the old "." pointer location is never overwritten. |
| 20:43:29 | sideral | Is the audio buffer even used for audio in the sim? |
| 20:43:56 | kugel | the corruption is visible after a reboot not reload for me |
| 20:46:40 | sideral | if I understand you correctly, this can be in either of two code paths in dircache_build −− with a known previous size and without. right? |
| 20:51:19 | * | sideral sees that dircache.c defines some functions twice, once for native and once for hosted |
| 20:53:24 | sideral | we may never execute the buggy function in the sim :) |
| 20:54:27 | kugel | that's certainly possible |
| 20:57:19 | | Part user829385 |
| 20:58:25 | | Join timccc [0] (~aoeu@112.166.15.141) |
| 20:58:47 | | Quit robin0800 (Ping timeout: 258 seconds) |
| 20:59:00 | | Quit sideral (Remote host closed the connection) |
| 20:59:23 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 21:00 |
| 21:00:31 | | Join FoH [0] (~foh@adsl-98-83-47-209.bhm.bellsouth.net) |
| 21:01:02 | | Quit bthomson (Ping timeout: 240 seconds) |
| 21:01:05 | | Quit FoH (Client Quit) |
| 21:01:29 | | Join robin0800 [0] (~robin0800@genld-217-248.t-mobile.co.uk) |
| 21:01:56 | | Join bthomson [0] (~bthomson@c-68-33-5-232.hsd1.va.comcast.net) |
| 21:03:09 | | Join FoH [0] (~foh@adsl-98-83-47-209.bhm.bellsouth.net) |
| 21:07:38 | kugel | gevaerts: I got the panic I introduced on hwcodec, need to look at that before committing |
| 21:07:56 | gevaerts | Sounds like a good idea :) |
| 21:08:09 | kugel | not sure if it's an existing problem or if I introduced a problem with my changes to mpeg.c |
| 21:08:34 | kugel | amiconn: there's a problem with probe_file_format() in svn |
| 21:09:18 | kugel | audio_formats[1] is all 0 because AFMT_MPA_L1 isn't set for hwcodec |
| 21:09:44 | kugel | that crashes in the sim because it's derefencing NULL |
| 21:10:07 | amiconn | Ah, you're talking about the sim |
| 21:10:18 | * | amiconn rarely uses that |
| 21:10:20 | | Quit robin0800 (Ping timeout: 246 seconds) |
| 21:10:43 | * | amiconn also can't do anything about it right now |
| 21:10:53 | kugel | I don't know if hwcodec can play mpeg layer 1, and you re-ordered that array a bit recently so I ping you :) |
| 21:12:20 | amiconn | No it can't - that's why I reordered it |
| 21:12:20 | | Quit ender` (Read error: Connection reset by peer) |
| 21:12:44 | kugel | then I guess probe_file_format needs to check for NULL |
| 21:12:48 | | Join ender` [0] (~ender@foo.eternallybored.org) |
| 21:12:56 | amiconn | Hwcodec can only play layer 2 and layer 3. |
| 21:14:00 | amiconn | Also hwcodec .talk clips are mp3, and the talk functions use that to check format. That's why the .talk extension must be present for layer 3 |
| 21:14:49 | | Quit user890104 (Remote host closed the connection) |
| 21:14:59 | | Join user890104 [0] (~Venci@83.228.31.135) |
| 21:17:00 | kugel | alternatively AFMT_MPA_L1 could be moved into the swcodec #ifdef |
| 21:17:11 | kugel | in the enum definitio |
| 21:17:38 | amiconn | Hmm, didn't I do this? |
| 21:17:45 | kugel | no |
| 21:30:01 | | Join robin0800 [0] (~robin0800@genld-219-248.t-mobile.co.uk) |
| 21:31:36 | | Join Stummi [0] (~Stummi@rockbox/developer/Stummi) |
| 21:31:50 | | Quit FoH (Quit: ¡ooʇ ‘ǝןdoǝd ǝɹɐ sʇɐq) |
| 21:32:48 | sideral | kugel: If you can reproduce the trash-name problem reliably, could bisect which revision introduced it? There are only a handful commits to dircache.c since 3.9 ;) |
| 21:35:08 | | Quit robin0800 (Quit: Leaving) |
| 21:41:52 | amiconn | sideral: While you're looking at the database code, you could have a look at this years old initiialisation bug (it's in the tracker iirc): db init never finishes if there are no audio tracks on the device (easiest test and probably most common case is to use a target with mmc/sd slot and no music on internal store, then try db init without a card iinserted) |
| 21:43:33 | sideral | amiconn: Yeah, I know of the bug and have even posted an updated patch to FS #9093, but I'm not confident enough in it yet. It seems to cause endless DB refreshes on some targets |
| 21:43:34 | fs-bluebot | http://www.rockbox.org/tracker/task/9093 Database initialization hangs if there's no music file on the player (bugs, assigned) |
| 21:47:10 | bertrik | [Saint], you're a wps expert, right? |
| 21:50:56 | bertrik | [Saint], last year during devcon we unified the clip and iriver 128x64x1 wps, but we lost the nice feature that the volume is shown in the wps for a few seconds after changing it (showing the volume bitmap later). Can you help restore this feature? |
| 21:50:59 | | Quit fdinel (Read error: Connection reset by peer) |
| 22:00 |
| 22:01:16 | bertrik | ah, I think I get it, I'll try it in the sim |
| 22:03:39 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 22:05:31 | *** | Saving seen data "./dancer.seen" |
| 22:12:26 | | Join fdinel [0] (~Miranda@modemcable036.124-131-66.mc.videotron.ca) |
| 22:12:27 | | Quit Stummi (Quit: Bye!) |
| 22:30:20 | bertrik | To get the dB value for one second, I basically just added %?mv<%pv| before the %?pv tag |
| 22:32:33 | bertrik | so basically, when volume changes (%?mv), the numeric volume (%pv) is shown, otherwise the bitmap volume bar (%?pv<%xd(Ca)... ) |
| 22:35:25 | | Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 22:36:42 | | Quit benedikt93 (Quit: Bye ;)) |
| 22:37:00 | | Quit stripwax (Ping timeout: 260 seconds) |
| 22:47:08 | | Join kevku [0] (x@2001:470:28:773:babe:feed:dead:beef) |
| 22:49:34 | bertrik | funman, I seem to have managed to restore the old cabbie v2 volume behaviour for the clips, showing the volume in dB while you're changing it, showing a volume bar when not changing the volume |
| 22:53:58 | funman | bertrik: nice, i like it |
| 22:54:16 | funman | volume bar is pretty, and volume dB is precise when you want to chance it |
| 22:59:42 | sideral | kugel: there's something I don't understand with the dircache compaction |
| 23:00 |
| 23:18:02 | | Join mystica555_ [0] (~mike@66-87-22-51.pools.spcsdns.net) |
| 23:20:36 | | Quit mrkiko (Ping timeout: 276 seconds) |
| 23:22:02 | | Join mrkiko [0] (~mrkiko@host46-250-dynamic.0-87-r.retail.telecomitalia.it) |
| 23:23:01 | | Quit mystica555_ (Ping timeout: 240 seconds) |
| 23:28:01 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 23:28:26 | kugelp | sideral: what don't you understand? |
| 23:29:59 | sideral | In the meantime I grokked it. I was confused by how many different ways are used to calculate buffer offsets in dircache_build and dircache_steal_buffer, but so far it appears correct |
| 23:30:35 | | Join mystica555_ [0] (~mike@64.202.138.67) |
| 23:32:12 | sideral | In passing, I found another buffer overrun in the database :) but it only occurs in 64-bit simulators and is totally benign (I believe), and definitely unrelated to the problem at hand |
| 23:33:18 | | Quit y4n (Quit: PÆNTS ØLF!) |
| 23:33:52 | | Quit mrkiko (Quit: leaving) |
| 23:39:24 | | Quit bertrik (Read error: Connection timed out) |
| 23:39:54 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 23:42:23 | sideral | kugel: Saw my note re bisecting? |
| 23:59:01 | | Quit mystica555_ (Ping timeout: 240 seconds) |
icon identifies that the person is a core developer (has commit access).