Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2011-07-30

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:42RuffbadHi
01:40:44Ruffbadis anyone on this irc?
01:42:30 Quit Ruffbad (Client Quit)
01:43:25 Join webguest34 [0] (~d06128a2@giant.haxx.se)
01:43:32webguest34Hello
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:50sideralHello 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:46sideralAdd 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:03sideralright :)
04:44:27sideral"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:19sideralDon'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:16sideral:)
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:23bluebroth3rforum admins: MyJuliet seems to be sig-spamming. Removed some posts that were unrelated to the threads posted in.
10:14:53JdGordonbanned
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:37bertrikI 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:44sideralthat's right, the last posting in this forum was a spam post
11:36:00sideral(according to the RSS feed)
11:40:56 Quit stoffel (Ping timeout: 246 seconds)
11:44:40bertrikI'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:27bertrikThe 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:47bertrikI'm wondering about a clean way of doing this.
11:46:10bertrikThe current way seems to be to just have a global variable for each variant.
11:47:02pamaurywhat do you propose instead of a global variable ?
11:47:41pamaurya global function returning the variant for each field ?
11:48:01bertriknot sure yet, maybe a system wide struct, to which you can get a pointer to read/modify things
11:49:45pamauryI 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:45bertrikpamaury, where var is a bitmap of various sub-model specific things or something similar?
11:52:26pamauryno a bitmap, just a number. Perhaps this would be cleaner: int target_get_variant(enum variant_t v)
11:52:37pamauryso you can do target_get_variant(LCD_TYPE);
11:53:01pamauryand target_set_variant(LCD_TYPE, SUPER_XVGA_4096x4096_LCD);
11:53:15pamaury:)
11:53:39bertriklike a (key,value) kind of thing
11:53:42 Join stoffel [0] (~quassel@p57B4B0FD.dip.t-dialin.net)
11:53:43pamauryyes.
11:54:32pamauryBut 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:59pamauryin 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:18bertrikpamaury, 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:22pamaurythat's another possibility but there might be other targets with other variants, so having a general mechanism can be useful
13:42:57pamauryyou 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:05bertrikfunny 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:24pamauryyeah 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:31bertrik(on the fuze v2)
15:04:01 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow)
15:06:40pamaurywere there lacking I/O pins up to this point ?
15:06:44pamaury*they
15:08:05bertrikDoesn'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:43GigaBrickHey, 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:13GigaBrickOh, so it's no longer a custom-entered figure?
15:53:24[Saint]It never has been afaik
15:53:50bertrikGigaBrick, 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:55GigaBrickHmm, 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:08GigaBrickWell, 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:08GigaBrickCould 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:13GigaBrickOh yeah, so I guess that wouldn't make sense
15:57:14GigaBrickWEird
15:57:34GigaBrickNow 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:38bertrikthe 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:38GigaBrickHmm... 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:43bertrikShould be configurable from 700 mAh to 1200 mAh, according to the source code
15:58:48GigaBrickBut 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:20GigaBrickOkay, [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:30GigaBrickSHould I still go ahead and update it again?
15:59:35[Saint]yeah, bug reports need to be off current svn
15:59:39GigaBrickk
15:59:49[Saint]in case it fixed itself and you end up wasting someones time ;)
15:59:56GigaBrickHeh, 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:26GigaBrickInstalling 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:44GigaBrickUsing "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:51bertrikGigaBrick, What target do you have exactly (I was assuming the gigabeat s)
16:04:59GigaBrickGigabeat F40
16:05:23***Saving seen data "./dancer.seen"
16:05:38 Join ender` [0] (~ender@foo.eternallybored.org)
16:06:12bertrikhm, ok that one is fixed to 830 mAh, but could easily be changed to allow a list of capacities
16:06:50GigaBrickCustom compilation?
16:07:42bertrikyes, 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:22bertrikIt was last changed in april 2009, probably not removed
16:09:42bertrikBefore 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:22GigaBrickYep
16:10:34GigaBrickI 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:13GigaBrickNo, 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:54GigaBrickI 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:07GigaBrickYeah, 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:01GigaBrickHeh, yeah, I don't think I'm going to wait quite as long either lol
16:17:39GigaBrickI think the compressor is my new favorite feature
16:17:44GigaBrickTHough I guess it's probably not very new at this point
16:17:51 Join sideral [0] (~sideral@rockbox/developer/sideral)
16:23:27GigaBrickSo I was thinking about modifying my source for a bit of a custom build
16:24:22GigaBrickI 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:32GigaBrickHeh, yeah, I have that loaded in my tab right now. :P
16:25:44[Saint]Do *NOT* use CygWin...
16:25:58GigaBrickHeh, 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:07GigaBrickHeh
16:26:14GigaBrickNah, I'm on Ubuntu Linux
16:26:20GigaBrickIs there any GCC version requirement?
16:26:44[Saint]There is, but our toolchain script pulls everything it needs.
16:27:08GigaBrickOh, okay, I think I might just use a virtualmachine like you guys suggest then
16:27:25GigaBrickI'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:33GigaBrick*dependencies
16:27:36[Saint]It won't touch the system GCC
16:28:04GigaBrickOh, well, seems I'll be good either way then. :D
16:28:28GigaBrickBut, 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:40GigaBrickI 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:56GigaBrickNo 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:49GigaBrickOh, 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:10GigaBrickOkay, 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:30GigaBrickI'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:05GigaBrickOkay, well either way I should be able to figure that stuff out, seems pretty straight forward
16:36:09GigaBrickThe Ui Simulator looks pretty neat
16:47:32kugelgevaerts: I would perhaps like to commit the one buffer_get_buffer() patch
16:48:46gevaertskugel: sounds like a sensible start
16:49:44kugelnot 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:45gevaertsTrue, 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:35gevaertsOf course there's also the observation that people tend to only look at things when they're committed...
17:00
17:06:30kugelgevaerts: have you read my comment on the task?
17:07:32gevaertsYes, I just read it
17:07:57gevaertsI think that's the simplest solution
17:11:32kugelperhaps not
17:11:56kugelscrobbler.c doesn't need any callbacks as such, but it does I/O with the buffer
17:18:28kugelso 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:21gevaertstrue
17:28:03 Quit mystica555_ (Ping timeout: 252 seconds)
17:34:44gevaertsThere'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:50gevaertshm
17:35:22gevaertsDidn't you say at some point that no callback meant no moving? Or do you mean scrobbler might use some default callback?
17:36:42kugelno callbacks means default callback, NULL callbacks means no move/shrink
17:36:56gevaertsright
17:37:58kugeli.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:27gevaertsDo you have some sort of idea about how many allocations there will be typically?
17:38:50kugelI think there are 15 or so currently
17:40:40gevaertsOk. 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:01kugelI think I still prefer BUFLIB_CB_DEFER_MOVE
17:45:10kugelit's more in line with the shrink callback
17:45:24gevaertsYes, 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:59kugelamiconn: svn crashes for me on hwcodec
18:20:03kugelin probe_file_format
18:20:45sideralkugel: My (probably dircache-related) problem of trash file and dir names persists despite my recent DB fixes
18:21:04kugelI thought that was fixed
18:21:24sideralI explicitly said I don't know yet :)
18:22:02kugelI thought r30122 fixed that
18:22:26sideralUnfortunately, it did not :(
18:23:18sideralThe 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:57sideralstill haven't been able to reproduce this with a simulator
18:24:39sideralThis is always with the rescan after a DB commit, so after the dircache has been reloaded
18:25:41kugelso without db there's no problem at all?
18:26:19kugeldoes the db reload the dircache indicies after the dircache is reloaded?
18:26:23sideralI 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:13sideralyou mean before/after the *tag*cache is reloaded?
18:27:30kugelno
18:27:36kugeldircache
18:27:40sideralafter a commit, the DB first reloads the dircache, then the DB ram cache
18:27:45kugele.g. after stealing the dircache buffer
18:28:20sideraland after that, another scan is triggered (likely for no good reason, but that's a different story ;) )
18:29:53kugelso there's no visible corruption, just that the db scans forever?
18:30:00sideralif that doesn't that answer your question, I've probably misunderstood it. what is a dircache index?
18:30:30kugelthe indicies returned by dircache_get_idx()
18:30:53kugelafaik they are cached by tagcache for filename tags
18:31:38sideralI don't know. The commit function calls dircache_build(0) to rebuild the dircache. Whatever that function does.
18:31:55kugelI mean does tagcache reload that cache
18:32:04kugelor discard
18:32:05sideralThe corruption is visible −− both in the file browser and in the DB debug screen (which shows the currently scanned file name)
18:32:25kugelI don't see that on my e200
18:33:21sideralkugel: 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:49kugelis there a way to trigger that corruption?
18:34:00kugeldo I need some setting? I don't see it
18:34:08 Quit FoH (Quit: Introducing X to a 'new' monitor.)
18:34:20sideralI have no reliable way to trigger it, but some of the ingredients are:
18:34:29sideral1. DB auto update enabled
18:34:33sideral2. dircache enabled
18:34:50kugeloh there is something
18:34:53sideral3. remove and add some files in USB mode
18:35:02sideral4. reboot to trigger autoupdate
18:35:19kugelI see an extra entry ".<some nonprintable char>" in each dir
18:35:26sideralthat's it
18:35:47sideralhow did you do it?
18:36:27kugel1. init db, 2. reboot, 3. enable dircache, 4. reboot, 5. insert sd, 6. reboot
18:36:36kugelit seems to be the . entry
18:37:34 Quit Strife89 (Read error: Connection reset by peer)
18:37:40sideralMy guess is that it's related to the dircache reload, that is, whatever happens in dircache_build(0)
18:39:40kugeldid you see other corruption or only this?
18:40:13 Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net)
18:40:30sideralI 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:41sideralThat's consistent with your hypothesis that it's the "." entry
18:40:58kugelit looks like there's garbage after the .
18:41:11kugelprobably making the strcmp(...,".") fail
18:41:27sideralyep
18:41:49kugel"." is at the very end of the dircache. perhaps some nasty thing overwrites the very last byte
18:41:57kugelwhich should be
18:42:08kugel \\0
18:42:40sideralre 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:15sideralperhaps your calculation of where ".\0" gets put has an off-by-one error?
18:43:31kugelthat's possible too
18:43:50kugelthis does happen when the cache is *not* compacted, right?
18:44:01kugel(only the initial dircache scan compacts)
18:44:03sideraltypically the DB is allocated immediately behind the dircache. when it gets reloaded, it overwrites the first few bytes (its ramcache_header)
18:44:19sideralI believe so
18:45:15sideralwhat does the trash look like? perhaps it's the ascii representation of a dircache header? :)
18:45:27kugelperhaps the db does alignment fixup wrongly?
18:45:55kugellike rounding down instead of up
18:46:10sideralthat's of course possible. let me have a look
18:46:46kugelI see that the dircache does strcpy the "." entry, so it's having the 0 byte
18:46:57kugelsomething must be overwriting that 0 byte afterwards
18:47:11sideralbut where to? maybe the target ptr is off by one?
18:48:09kugelbefore generate_dot_dnames(), d_names_start == d_names_end (pointing to the first byte after the cache)
18:48:18sideralthe tagcache uses buffer_alloc to allocate the ram cache, which rounds up
18:48:27kugelthen dot = d_names_start - 2 (for '.' and 0)
18:49:15sideralthose entries are recreated every time the dircache is rebuild, right?
18:49:18kugelyes
18:50:15 Join z180 [0] (~chatzilla@ip-2-202-230-152.web.vodafone.de)
18:52:26z180you could try to find some of the DB related bugs via code checkers like clang or cpppcheck
18:53:26sideralkugel: Could you check whether you can reproduce the error with the simulator with the same steps?
18:53:43kugeldoes the sim have a sd? :(
18:53:50sideralthe you could set a hardware breakpoint at the end of the dircache
18:54:05sideralkugel: yeah, simply add the files on your sim to your simdisk
18:54:29siderals/sim/SD/
18:54:40z180does your sim bzero() out its RAM?
18:55:22sideralz180: not sure
18:57:08 Part Toes ("Leaving")
19:00
19:02:35sideralkugel: when is the code path with the second if in dircache_build used?
19:02:56pamauryis 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:57pamaury?
19:03:36sideralkugel: 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:49z180you talk about the nano 4g?
19:05:55sideralz180: 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:54mrkikoHi 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:17gevaertsno
19:15:39 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
19:15:46TheLemonMansamsung vibe ?
19:16:13 Quit Strife89 (Ping timeout: 250 seconds)
19:17:35kugelsideral: when the dircache size is known from the previous boot
19:18:06kugelthat's the normal case I'd say
19:18:39z180mrkiko look if someone has disassembled and what CPU is inside
19:19:55z180sideral 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:47sideralkugel: Oh, then the missing allocated_size fixup might be the problem?
19:22:37kugelwhat do you mean?
19:22:55kugelALIGN_BUFFER does that, no?
19:23:09sideraloh does it? darn :)
19:23:43kugelit rounds up the pounter and rounds down pointer+size
19:24:41pamauryz180: my comment was totally unrelated to anything in the chan :)
19:25:04sideralOK, good. I was wondering anyway why an error there would cause a reload to fail :)
19:25:11sideralkugel: ^
19:25:32kugelthe sim doesn't notice when I add files outside
19:25:49sideraldo you have autoupdate enabled?
19:26:04kugelautoupdate is unrelated
19:26:06sideraland you need to restart the sim, of course :)
19:26:11kugelit doesn't notice because dircache is active
19:26:47kugelthat doesn't expose the problem
19:27:33sideralhuh? your recipe had a reboot there.
19:28:09kugelright
19:28:21kugelbut it doesn't show the problem anyway :)
19:28:34sideraldang
19:28:39pamauryTheLemonMan: any progress with your port ?
19:28:41kugeltoggling the SD seems to be enough on my e200 apparently
19:28:58sideralis the DB update involved at all on your e200?
19:29:16TheLemonManthe dma seems to work but the nand is stuck in WAITING_WRITE mode forever
19:29:51pamauryyou can read from the nand ?
19:30:06kugelsideral: the show files setting seems to make a difference
19:30:27kugelsideral: don't know. it's initialized but I don't have autoupdate enabled
19:30:32TheLemonManit's stuck when sending the command
19:30:38sideralah, show files, obviously :)
19:31:05kugelthe sim crashes if it's on
19:31:09kugelon show all
19:31:14sideralthat's good!
19:31:31sideralnow enter "gdb rockboxui" ;)
19:32:52kugelhm, dircache_gen_next() fails
19:33:33kugelno wait
19:33:42*sideral waits
19:34:27kugelhttp://pastie.org/2295297
19:34:32sideralI suggest to set a write breakpoint at the \0 byte of the "." entry
19:34:49kugelthe crash is a separate problem it seems
19:35:14sideralstack overflow due to nesting loop of "." entries?
19:38:04kugelI don't think the sim can stkov
19:38:14sideralprint ce
19:38:22kugeloh well it can
19:38:26kugelsince my threading rework
19:38:32kugelce is NULL
19:39:00kugelbut it's not clear whether the ce passed to sab_process_dir was also NULL (gdb says so, but I doubt it)
19:39:03sideralallocate_entry may have failed
19:39:45sideralI think you should try catching that ".\0" overwrite first
19:40:22kugelsideral: I need to get the sim to start up first :)
19:40:27sideralwith a hardware watchpoint, enabled right after generate_dot_d_names
19:40:58sideralwhere you should set a breakpoint
19:41:24sideralyou can set breakpoints before running the program
19:41:52sideralBTW, are you using an SDL-thread enabled sim?
19:41:55kugelno
19:42:38kugelohh, the cache is now 4MB, there's clearly something wrong
19:43:30sideralthat means its scan is recursing somewhere. probably that "." loop again
19:44:01sideralyou really should set a breakpoint before it does that :)
19:45:36sideralkugel: will you be around later tonight? I'm taking a dinner break now
19:47:18kugelit looks like
19:47:54sideral:) 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:59z180do rockbox guys help reversing on freemyipod.org?
19:57:57timccconly 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:42gevaertsz180: 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:45kugelsideral: I can't repo in the sim
20:02:22 Quit Horscht (Ping timeout: 276 seconds)
20:02:30sideralkugel: oh?
20:02:48kugelmy crash was the result of recursive symbolic links :)
20:03:11sideralbut I thought you saw the corrupted dir entries in the sim?
20:03:20kugelno
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:00sideralwhy would "show files" make any difference?
20:07:31kugelthe corrupted entry is hidden
20:07:54kugelstrange it's not reproducible with the sim
20:09:25 Quit robin0800 (Ping timeout: 255 seconds)
20:09:30kugeloha
20:09:33*sideral is confused the entry corrupted by the recursive symlink?
20:09:49kugeld_names_end and dot/dotdot are completely differnet addresses
20:10:00kugelsideral: no the crash I had in the sim
20:10:15kugelI only had the corrupted entry on the e200 target
20:10:20kugel(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:37sideralinteresting!
20:11:58kugelmeh, 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:03kugelhah! I think I have it
20:15:12sideraland?
20:15:25kugeldot and dotdot aren't update after compaction
20:15:39sideraloops
20:15:49kugelnew entries (that go into the reserve buffer) get the old values
20:18:53sideralkugel: are you still sure you want to introduce movable allocations as part of your GSoC work? :)
20:19:10kugelI don't think I have much choice :)
20:19:10sideralTo me it seems more and more clear that moving stuff around introduces complexity and hard to find bugs
20:19:38sideralWell, I outlined an alternative a few weeks ago
20:20:51kugelhm, 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:05sideraldo existing dircache entries also reference the old dotfile-name locations?
20:23:25 Quit TheLemonMan (Quit: .)
20:23:37kugeln
20:23:38kugelno
20:23:46kugelthey shouldnt :)
20:24:55sideralas the trash name appears in all directories, perhaps they actually do?
20:25:20sideralyou should be able to check with the debugger...
20:26:15kugelsideral: I repeat once more: I don't see the corruption in the sim
20:26:17 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm)
20:27:08sideralwell, not on the screen. but you saw the ptr inconsistency in the sim, didn't you?
20:28:10kugelthe entries point to the right thing
20:28:25sideralOK, that's what I was wondering
20:29:02sideralcan you put up your patch (pastebin)?
20:29:45kugelhttp://pastie.org/2295462
20:30:12kugelI'm now trying to replicate the e200 behavior in the sim by somehow posting a SYS_FS_CHANGED event
20:30:33kugelbut 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:51sideralperhaps 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:56kugelI tried that
20:35:25kugelmeh, 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:24kugelsideral: with usb simulation the dircache is also reloaded. but I still cannot manage to repro
20:42:17sideralwhat do the pointers look like in the sim after the dircache is reloaded?
20:43:16sideralI'm hypothesizing that you'll never see any corruption in the sim because the old "." pointer location is never overwritten.
20:43:29sideralIs the audio buffer even used for audio in the sim?
20:43:56kugelthe corruption is visible after a reboot not reload for me
20:46:40sideralif 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:24sideralwe may never execute the buggy function in the sim :)
20:54:27kugelthat'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:38kugelgevaerts: I got the panic I introduced on hwcodec, need to look at that before committing
21:07:56gevaertsSounds like a good idea :)
21:08:09kugelnot sure if it's an existing problem or if I introduced a problem with my changes to mpeg.c
21:08:34kugelamiconn: there's a problem with probe_file_format() in svn
21:09:18kugelaudio_formats[1] is all 0 because AFMT_MPA_L1 isn't set for hwcodec
21:09:44kugelthat crashes in the sim because it's derefencing NULL
21:10:07amiconnAh, 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:53kugelI 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:20amiconnNo it can't - that's why I reordered it
21:12:20 Quit ender` (Read error: Connection reset by peer)
21:12:44kugelthen I guess probe_file_format needs to check for NULL
21:12:48 Join ender` [0] (~ender@foo.eternallybored.org)
21:12:56amiconnHwcodec can only play layer 2 and layer 3.
21:14:00amiconnAlso 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:00kugelalternatively AFMT_MPA_L1 could be moved into the swcodec #ifdef
21:17:11kugelin the enum definitio
21:17:38amiconnHmm, didn't I do this?
21:17:45kugelno
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:48sideralkugel: 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:52amiconnsideral: 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:33sideralamiconn: 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:34fs-bluebothttp://www.rockbox.org/tracker/task/9093 Database initialization hangs if there's no music file on the player (bugs, assigned)
21:47:10bertrik[Saint], you're a wps expert, right?
21:50:56bertrik[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:16bertrikah, 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:20bertrikTo get the dB value for one second, I basically just added %?mv<%pv| before the %?pv tag
22:32:33bertrikso 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:34bertrikfunman, 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:58funmanbertrik: nice, i like it
22:54:16funmanvolume bar is pretty, and volume dB is precise when you want to chance it
22:59:42sideralkugel: 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:26kugelpsideral: what don't you understand?
23:29:59sideralIn 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:12sideralIn 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:23sideralkugel: Saw my note re bisecting?
23:59:01 Quit mystica555_ (Ping timeout: 240 seconds)

Previous day | Next day