| 00:05:20 | | Quit domonoky1 (Read error: Connection reset by peer) |
| 00:06:49 | | Join robin0800 [0] (~robin0800@149.254.180.235) |
| 00:08:07 | | Join TheSeven [0] (5d84be41@rockbox/developer/TheSeven) |
| 00:21:31 | | Join s1gma_ [0] (~d.d.derp@77.107.164.131) |
| 00:22:38 | | Quit _s1gma (Ping timeout: 276 seconds) |
| 00:22:55 | | Join insp_ [0] (~chatzilla@customer-217.241.livas.lv) |
| 00:39:15 | | Quit Staphylo (Quit: Bye les gens =)) |
| 00:43:59 | | Quit GeekShadow (Quit: The cake is a lie !) |
| 00:46:39 | CIA-81 | New commit by Buschel (r28165): Add current consumption and battery capacities to iPod nano 2G config file. |
| 00:47:46 | * | TheSeven likes the fact that Buschel steals items from his todo list :) |
| 00:48:16 | Buschel | :-) the battery bench and the discharge curve is still missing though |
| 00:48:21 | CIA-81 | r28165 build result: All green |
| 00:48:33 | * | TheSeven committed a discharge curve once |
| 00:49:34 | TheSeven | hm, someone stole that, too |
| 00:50:09 | Buschel | yes, there is one. but to me it seems the included one will reach 0% too early |
| 00:50:27 | Buschel | btw, any chance to work on LCD_SLEEP? |
| 00:50:40 | Buschel | this might bring in some more savings... |
| 00:51:37 | TheSeven | ah, there it is |
| 00:51:40 | TheSeven | it only moved a bit |
| 00:51:43 | TheSeven | const unsigned short percent_to_volt_discharge[BATTERY_TYPES_COUNT][11] = { { 3550, 3783, 3830, 3882, 3911, 3949, 3996, 4067, 4148, 4228, 4310 } }; |
| 00:51:50 | TheSeven | looks fine to me |
| 00:53:35 | TheSeven | i tweaked the lowest two values a bit to give a better average accuracy in the nearly-empty area |
| 00:54:56 | TheSeven | shutoff at 3.35V was needed so that the ipod has enough charge left to do a worst-case ftl commit (about 30 seconds of writing to flash) |
| 00:55:05 | Buschel | don't you think it would be better to even use lower voltages for "dangerous" and "shutoff"? both are >>3.0V which is the lowest voltage used player internally (from what I can see) |
| 00:55:10 | TheSeven | the flash is powered through an LDO linear regulator at 3.00V |
| 00:55:30 | TheSeven | so we need to still be a bit above of that to make it work in a stable fasion |
| 00:55:31 | Buschel | ah, you just typed the answer for the question I was asking |
| 00:56:00 | Buschel | so, then the battery stuff is finished :) |
| 00:56:03 | TheSeven | the voltage falls rather fast starting at about 3.30V |
| 00:56:17 | TheSeven | at 2.90V the CPU will die |
| 00:56:52 | TheSeven | i don't know if the power manager shuts it off deliberately or if it just fails because the RAM voltage drops too much (it's also configured at 3.00V) |
| 00:57:17 | TheSeven | the CPU internally runs at 1.00V or 1.05V through a switching regulator |
| 00:57:47 | Buschel | is it possible to use lower voltage when the cpu is clocked down to 48 MHz? |
| 00:58:08 | TheSeven | yes, I managed to get it down to 0.95V but that doesn't save much |
| 00:58:17 | Buschel | no |
| 00:58:25 | TheSeven | it even seems to run at that voltage at 200MHz |
| 00:58:40 | Buschel | what were the savings? |
| 00:58:47 | Buschel | <1 mA? |
| 00:58:47 | TheSeven | maybe 1mA |
| 00:59:04 | TheSeven | the problem is that the XTAL oscillator frequency drops noticably below 0.925V on mine |
| 00:59:25 | TheSeven | this was reported to happen at even higher voltages on some devices |
| 00:59:52 | TheSeven | i once managed to run it at 0.85V at 48MHz, but the real cpu clock was more like 43MHz |
| 01:00 |
| 01:00:30 | * | TheSeven didn't know that xtal oscillators can behave that badly |
| 01:00:53 | TheSeven | the problem with frequency-dependent undervolting is that switching the voltage takes way too long |
| 01:01:11 | TheSeven | apparently the cpu frequency change function can be invoked from an IRQ context |
| 01:01:30 | | Quit insp_ (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]) |
| 01:01:36 | TheSeven | and we need to wait for I2C transactions to complete and voltages to stabilize before raising the clock again |
| 01:01:50 | TheSeven | if that could be split into multiple operations, this might help |
| 01:01:59 | TheSeven | but I can't block IRQs for that long without disrupting playback |
| 01:02:25 | Buschel | so, best would be to either find a lower voltage that also fits for 192MHz or just keep the actual voltage |
| 01:02:49 | TheSeven | that I2S core is extremely sensitive to FIQ latencies |
| 01:02:50 | | Quit s1gma_ (Ping timeout: 265 seconds) |
| 01:03:11 | TheSeven | more than about 20 *microseconds* of latency until the next DMA transfer is started and you'll notice clicking |
| 01:03:48 | TheSeven | so we can't even afford to lock FIQs while waiting for a PLL to lock |
| 01:04:25 | TheSeven | (that's why I'm using an assembly FIQ handler) |
| 01:04:40 | Buschel | that's why you are using the fastbus-option to force the cpu clock to 48 MHz? |
| 01:04:45 | TheSeven | yes |
| 01:04:49 | Buschel | ok |
| 01:04:52 | | Join Nausicaa [0] (~Nausicaa@c-71-239-58-153.hsd1.il.comcast.net) |
| 01:04:57 | TheSeven | i can't stop the pll, because I don't manage to get it running again fast enough |
| 01:05:35 | TheSeven | if we would change the core in a way that allows boosting/unboosting to be split into multiple operations, that might help |
| 01:05:50 | TheSeven | or at least get rid of the calls from IRQ context |
| 01:05:58 | TheSeven | that would allow us to block at least |
| 01:06:07 | TheSeven | then we could also change the voltage |
| 01:06:17 | TheSeven | powering down the unused PLL saves about 2mA IIRC |
| 01:06:40 | Buschel | do we already do this? |
| 01:06:47 | soap | Has any disassembly been done on the OF? |
| 01:06:57 | TheSeven | a bit, but not much of it |
| 01:07:25 | TheSeven | most of it was reverse engineered from the apple bootloader and diagmode |
| 01:08:02 | soap | I'm curious if any knowledge has been gleaned on how the OF manages the CPU frequency, since it sounds much harder to maximize part-turnoff-savings than on the previous ipods I was curious if the OF even bothered. |
| 01:08:25 | * | TheSeven has no idea |
| 01:08:29 | soap | (not that I have ANY insights, just curiosity) |
| 01:08:51 | TheSeven | one might want to look at their FIQ handler |
| 01:09:02 | TheSeven | they might have found a better way to deal with the I2S DMA |
| 01:09:26 | TheSeven | auto-reloading DMA didn't work for me for some reason, and they didn't use it in diagmode at all |
| 01:10:37 | | Quit Highlander (Quit: Quitte) |
| 01:12:42 | | Quit engwan_ (Ping timeout: 276 seconds) |
| 01:14:51 | Buschel | TheSeven: the LCD driver has lots of waits between each 16 bit write access to the 16bit data register. if I remove one of those waits between 2 write accesses, the speed is increased and i can see no visible impact to the screen. |
| 01:18:21 | | Quit TheSeven (Ping timeout: 252 seconds) |
| 01:23:23 | | Join _s1gma [0] (~d.d.derp@77.107.164.131) |
| 01:23:45 | | Quit robin0800 (Ping timeout: 276 seconds) |
| 01:29:35 | soap | Buschel, http://forums.rockbox.org/index.php?topic=25800.msg172289#msg172289 |
| 01:29:48 | soap | second half of his post might be relevant to you. |
| 01:30:23 | soap | 28164 to blame? |
| 01:32:29 | Buschel | soap: yep. works for me though... will create a flyspray patch. it might be connected to different LCD types... |
| 01:32:43 | | Join TheSeven [0] (5d84be41@rockbox/developer/TheSeven) |
| 01:33:04 | TheSeven | sorry, webchat went dead for some reason |
| 01:33:16 | TheSeven | but in the meantime i had a quick glance at the OF's FIQ handler: |
| 01:33:19 | TheSeven | STMFD SP!, {R0-R12,LR} |
| 01:33:39 | TheSeven | apparently they didn't quite realize what kind of advantage an FIQ offers in terms of registers |
| 01:33:52 | | Quit PaulJam (Ping timeout: 272 seconds) |
| 01:33:59 | TheSeven | so I think they aren't suffering as bad from the latency problem as we are |
| 01:35:13 | TheSeven | actually an FIQ seems to be considered a fatal error |
| 01:37:15 | CIA-81 | New commit by Buschel (r28166): Roll back r28164 as this change introduced LCD issues on some nano 2G. |
| 01:38:47 | CIA-81 | r28166 build result: All green |
| 01:39:35 | | Join antil33t1 [0] (~Mudkips@124-197-51-80.callplus.net.nz) |
| 01:39:39 | | Quit antil33t (Disconnected by services) |
| 01:42:54 | TheSeven | their IRQ handler seems to be doing a context switch |
| 01:43:00 | TheSeven | not very latency-oriented either |
| 01:44:11 | Buschel | TheSeven: You have got a type1 or type0 LCD in your nano 2g? |
| 01:45:02 | * | TheSeven doesn't remember the way they were numbered |
| 01:45:05 | TheSeven | I have the LDS176 |
| 01:45:29 | Buschel | same than I have... |
| 01:46:30 | TheSeven | if you need init code, there's some code in norloader/embios loader that should do the trick, but it's a bit fishy |
| 01:47:11 | TheSeven | also IIRC there's a patch on flyspray that's dealing with LCD shutdown, don't remember if it was yours or liar's or someone else |
| 01:51:14 | *** | Saving seen data "./dancer.seen" |
| 01:53:17 | * | clone4crw wonders if gui_synclist is documented in a way that makes sense to someone who's never used it before. |
| 01:56:06 | | Quit Zambezi (Read error: Connection reset by peer) |
| 02:00 |
| 02:00:43 | | Quit DerPapst (Quit: Leaving.) |
| 02:04:20 | TheSeven | this is just ridiculous |
| 02:04:52 | * | TheSeven has never seen such an inefficient IRQ handler before |
| 02:14:49 | | Join Zambezi [0] (~Zulu@80.67.9.2) |
| 02:15:29 | * | TheSeven doesn't manage to figure out where the handlers for the individual IRQs are |
| 02:16:00 | | Quit clone4crw (Remote host closed the connection) |
| 02:16:09 | TheSeven | i found the place calling them, but can't find anything that's writing to that table after it is initialized (zeroed) and before it is used |
| 02:18:32 | | Join NoGare [0] (~barry@unaffiliated/nogare) |
| 02:22:30 | TheSeven | this crazy thing is dealing with linked lists of structs just to do the IRQ mapping apparently |
| 02:23:48 | TheSeven | apparently that beast is even calling malloc() in the irq handler... |
| 02:39:10 | | Join Synthbox [0] (~x@95.111.3.99) |
| 02:40:07 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 02:44:48 | | Join kugel_ [0] (~kugel@g231105197.adsl.alicedsl.de) |
| 02:45:10 | | Quit kugel (Disconnected by services) |
| 02:45:15 | | Nick kugel_ is now known as kugel (~kugel@g231105197.adsl.alicedsl.de) |
| 02:45:19 | | Quit kugel (Changing host) |
| 02:45:19 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 02:48:30 | * | TheSeven just spotted the timer irq handler, but that's the only one that's registered from known code |
| 02:48:45 | TheSeven | there are probably more calls to this one in sections not yet marked as code |
| 02:53:03 | | Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) |
| 02:54:58 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 03:00 |
| 03:03:30 | | Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854]) |
| 03:07:04 | TheSeven | Buschel (for the logs): re r28161: I don't think this will make a difference at all |
| 03:07:44 | TheSeven | this is probably in the range of a few microamps |
| 03:08:30 | TheSeven | did you verify that one can still wake up the ipod after powering down with the hold switch locked with that change? |
| 03:10:43 | TheSeven | and re: #define CURRENT_NORMAL 21 /* playback @48MHz clock, backlight off */ |
| 03:10:52 | TheSeven | this appears to be a bit too high to me |
| 03:11:08 | TheSeven | IIRC i had values around 18mA on mine |
| 03:11:54 | | Quit MethoS- (Remote host closed the connection) |
| 03:12:01 | TheSeven | just tried and got 40mA! wtf? |
| 03:13:12 | TheSeven | aha. usb seems to be the culprit |
| 03:14:11 | TheSeven | after plugging unplugging usb: backlight off: 17-18mA, backlight on (brightness 24): 23-24mA |
| 03:14:34 | TheSeven | at brightness 46 I get 42-43mA |
| 03:15:33 | TheSeven | (measured at 4.19V battery voltage, 320kbps mp3) |
| 03:17:30 | TheSeven | with 16 ohms earphones at -1db (clipping limit), it's at 17-31mA |
| 03:18:06 | TheSeven | 17-18mA at -20dB |
| 03:18:43 | TheSeven | measurements done using r28047M |
| 03:21:34 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 03:22:15 | | Quit kugel (Remote host closed the connection) |
| 03:36:48 | * | TheSeven just located the DMA IRQ handler |
| 03:43:59 | | Join Kitr88 [0] (~Kitarist@BSN-210-238-138.dial-up.dsl.siol.net) |
| 03:46:52 | | Quit Kitar|st (Ping timeout: 240 seconds) |
| 03:48:36 | | Quit Kitr88 (Ping timeout: 255 seconds) |
| 03:51:18 | *** | Saving seen data "./dancer.seen" |
| 03:53:58 | | Join Kitar|st [0] (Kitarist@BSN-182-103-230.dial-up.dsl.siol.net) |
| 04:00 |
| 04:01:35 | | Join mikewkrc [0] (~mikew@74-140-49-181.dhcp.insightbb.com) |
| 04:03:51 | mikewkrc | wow somebody spent a really long time putting together the "read this first" |
| 04:14:43 | mikewkrc | brb rebooting into unbuntu for first try at running a patch/compile of rockbox :) (wishing myself luck :) ) |
| 04:14:59 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 04:15:06 | | Quit mikewkrc () |
| 04:19:15 | | Join mikewkrc [0] (~rewt@74-140-49-181.dhcp.insightbb.com) |
| 04:21:27 | | Quit NoGare (Quit: leaving) |
| 04:25:22 | | Quit pixelma (Disconnected by services) |
| 04:25:23 | | Quit amiconn (Disconnected by services) |
| 04:25:24 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:25:25 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:25:26 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:25:31 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:25:55 | | Quit Synthbox (Ping timeout: 240 seconds) |
| 04:39:22 | mikewkrc | Thank the computer gods for inventing i7 compiling is sooo fast |
| 04:47:28 | | Join clone4crw [0] (~calvin@97-86-227-168.dhcp.roch.mn.charter.com) |
| 04:49:10 | mikewkrc | compiling with a 1.8 system load :) |
| 04:53:10 | | Join Barahir_ [0] (~jonathan@frnk-590fc701.pool.mediaWays.net) |
| 04:57:01 | | Quit Barahir (Ping timeout: 276 seconds) |
| 04:59:10 | soap | you need faster drives. |
| 05:00 |
| 05:02:08 | mikewkrc | holy crap it worked |
| 05:02:23 | mikewkrc | installed psgroove through rockbox first try :) |
| 05:02:29 | mikewkrc | on my sansa e260 |
| 05:04:07 | | Join xavieran [0] (~xavieran@ppp118-209-81-14.lns20.mel4.internode.on.net) |
| 05:04:33 | | Quit xavieran (Remote host closed the connection) |
| 05:04:52 | | Quit Zambezi (Read error: Connection reset by peer) |
| 05:05:04 | | Join xavieran [0] (~xavieran@ppp118-209-81-14.lns20.mel4.internode.on.net) |
| 05:05:57 | | Quit rvvs89 (Ping timeout: 272 seconds) |
| 05:14:27 | | Join Zambezi [0] (Zulu@80.67.9.2) |
| 05:20:32 | | Quit _s1gma (Quit: Leaving) |
| 05:31:47 | | Quit ps-auxw (Read error: Operation timed out) |
| 05:36:49 | | Quit Zambezi (Read error: Connection reset by peer) |
| 05:39:28 | | Join rvvs89 [0] (rvvs89@pdpc/supporter/base/rvvs89) |
| 05:40:02 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 05:45:21 | | Join ps-auxw [0] (~arneb@p4FF7F9D4.dip.t-dialin.net) |
| 05:51:20 | *** | Saving seen data "./dancer.seen" |
| 05:54:32 | | Join clone4cr1 [0] (~calvin@97-86-227-168.dhcp.roch.mn.charter.com) |
| 05:57:14 | | Quit clone4crw (Ping timeout: 255 seconds) |
| 05:58:43 | | Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 05:58:55 | | Quit clone4cr1 (Ping timeout: 240 seconds) |
| 06:00 |
| 06:02:06 | | Join fyre^OS [0] (~nnscript@cpe-68-173-233-99.nyc.res.rr.com) |
| 06:04:38 | | Quit fyrestorm (Ping timeout: 276 seconds) |
| 06:17:02 | | Quit bluebroth3r (Ping timeout: 255 seconds) |
| 06:18:45 | | Join bluebrother [0] (~dom@f053154227.adsl.alicedsl.de) |
| 06:18:45 | | Quit bluebrother (Changing host) |
| 06:18:45 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 06:28:09 | | Join engwan_ [0] (~engwan@112.202.22.199) |
| 06:48:46 | | Join Zambezi [0] (Zulu@80.67.9.2) |
| 07:00 |
| 07:02:59 | | Quit sasquatch (Ping timeout: 276 seconds) |
| 07:06:42 | | Join sasquatch [0] (~username@212.23.105.235) |
| 07:18:41 | | Join dys [0] (~andreas@krlh-5f727fbf.pool.mediaWays.net) |
| 07:22:59 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 07:25:05 | | Quit Horschti (Ping timeout: 265 seconds) |
| 07:41:59 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 07:47:19 | | Quit anewuser () |
| 07:51:21 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:09:55 | * | JdGordon contemplates bringing up the question of making the quickscreen button customisable to be either the QS or hotkey.... |
| 08:15:28 | | Quit slothearn (Quit: Lost terminal) |
| 08:16:19 | | Quit Nausicaa (Ping timeout: 265 seconds) |
| 08:19:30 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 08:35:41 | | Join Jaykay [0] (~chatzilla@p5DC56E2B.dip.t-dialin.net) |
| 08:43:36 | CIA-81 | New commit by jdgordon (r28167): Fix FS #1159 - stack overflow in the skin engine when there is too many nested conditionals |
| 08:45:30 | CIA-81 | r28167 build result: All green |
| 08:47:10 | JdGordon | why are 3 of those builds such a large green delta? |
| 09:00 |
| 09:03:37 | | Join Rob2223 [0] (~Miranda@p4FDCBA96.dip.t-dialin.net) |
| 09:03:48 | bertrik | I saw some corruption in the wps (default cabbiev2) on my clip+ yesterday, but it only happened when timestretch was enabled. I also saw a comment on the forums from someone who got data aborts with timestretch enabled. |
| 09:03:59 | bertrik | I guess something's dodgy with timestretch. |
| 09:06:17 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 09:06:35 | * | JdGordon slaps kugel for commiting // comments |
| 09:06:35 | | Quit Rob2222 (Ping timeout: 240 seconds) |
| 09:06:49 | | Join Spaceghost1 [0] (~pidgin@unaffiliated/spaceghost) |
| 09:07:00 | Spaceghost1 | hello folks |
| 09:07:44 | Spaceghost1 | I read here: http://www.rockbox.org/wiki/MiniCF |
| 09:08:06 | Spaceghost1 | that this memory Transcend 32GB 133x CF card worked on a 2g Mini |
| 09:08:38 | Spaceghost1 | if that card worked on the mini, probabily that http://www.dealextreme.com/details.dx/sku.11298 |
| 09:09:40 | Spaceghost1 | will work on a 4th generation ipod if I buy a 1.8 to CF adapter? like that: http://www.dealextreme.com/details.dx/sku.10886 |
| 09:09:41 | Spaceghost1 | ?? |
| 09:10:03 | JdGordon | it should |
| 09:11:36 | Spaceghost1 | ok |
| 09:12:04 | Spaceghost1 | what about use a microphone on ipod? |
| 09:12:16 | Spaceghost1 | is really hard get one that work very well on it? |
| 09:13:24 | Spaceghost1 | if I think give (in others) that use to the iphone, probabily is better that buy another cheap player? |
| 09:14:02 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 09:14:16 | | Quit Judas_PhD (Client Quit) |
| 09:17:06 | | Quit AoEKiller () |
| 09:21:20 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 09:32:19 | CIA-81 | New commit by jdgordon (r28168): Fix FS #11552 - touches outside of the UI viewport can do unexpected list movements. ... |
| 09:34:05 | CIA-81 | r28168 build result: All green |
| 09:45:42 | | Join Buschel [0] (~chatzilla@p54B67541.dip.t-dialin.net) |
| 09:46:18 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 09:49:29 | Buschel | TheSeven: I measured the 21 mA with headphone at about -30dB, backlight off and playing mpc files. in this state the debug screen showed 20-21 mA. this also perfectly matches a runtime test I have done −− result was ~19h. |
| 09:51:09 | Buschel | TheSeven: and of course this was measured after a clean restart. |
| 09:51:22 | *** | Saving seen data "./dancer.seen" |
| 09:56:47 | Buschel | TheSeven: from a psychological point of view it is imho the better choice to perform better in real life than the pure numbers say :-) |
| 09:58:15 | | Quit Guest934 (Ping timeout: 264 seconds) |
| 10:00 |
| 10:10:24 | Buschel | TheSeven: just retested -> still 20-21 mA. only when using 950mV for the CPU I get 18-20 mA. |
| 10:11:55 | | Quit scorche (Read error: Connection reset by peer) |
| 10:15:36 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 10:15:38 | | Join PaulJam [0] (~Paule@p54BEA836.dip.t-dialin.net) |
| 10:16:56 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 10:18:23 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 10:20:44 | | Quit sasquatch (Ping timeout: 276 seconds) |
| 10:24:07 | Spaceghost1 | :/ |
| 10:29:53 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 10:33:05 | | Join sasquatch [0] (~username@df01ppp031.eplus-online.de) |
| 10:43:25 | pixelma | bertrik: the screen corruption thing is a bit irregular for me (e.g. on my own Ondio WPS I usually don't see corruption but sometimes a few bitmaps are missing but can reappear after reboots or reloads of the theme, got a few unnecessary pixels only once) |
| 10:44:10 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:50:15 | | Join Spaceghost [0] (~pidgin@unaffiliated/spaceghost) |
| 10:53:03 | | Quit Spaceghost1 (Ping timeout: 272 seconds) |
| 10:54:00 | bertrik | pixelma, I noticed that timestretch uses buffer_alloc to get memory and I guess the skin stuff does too. Maybe we could add some debugging to that. |
| 10:54:34 | | Quit scorche (Read error: Connection reset by peer) |
| 10:55:20 | bertrik | Like adding magic markers / ids around the allocated memory blocks and checking them regularly |
| 10:55:55 | n1s | bertrik: you mean like the canary value we use on stacks? |
| 10:56:05 | n1s | to check for overflow |
| 10:56:44 | gevaerts | sounds like a good idea |
| 10:57:43 | n1s | yeah, memory corruption is no fun to debug |
| 10:58:09 | bertrik | Maybe a buffer_alloc is silently failing, resulting in corruption later on |
| 10:58:54 | JdGordon | I dont think so |
| 10:58:57 | JdGordon | I mean, I doubt it |
| 10:59:08 | bertrik | I see there is currently no protection/check against too much memory allocated. |
| 11:00 |
| 11:00:55 | n1s | yeah, buffer_alloc just increments the audiobuf pointer with the requested size with no checks whatsoever |
| 11:01:21 | | Quit amiconn (Remote host closed the connection) |
| 11:01:22 | | Quit pixelma (Remote host closed the connection) |
| 11:01:34 | | Join pixelma [0] (quassel@rockbox/staff/pixelma) |
| 11:01:47 | | Join amiconn [0] (quassel@rockbox/developer/amiconn) |
| 11:03:45 | n1s | a simple if (audiobuf+size > audiobufend) return NULL; should do no? |
| 11:04:03 | n1s | and some checking in the places that do the allocations of course |
| 11:04:25 | JdGordon | well yes and no |
| 11:04:44 | JdGordon | isnt the problem that alot of things wont fail gracefully if it doesnt get the ram |
| 11:04:58 | | Quit bertrik (Read error: Connection timed out) |
| 11:05:27 | n1s | that is buggy then and should be fixed, i think allocating memory that doesn't exist (or even memory allocated by something else) is worse |
| 11:05:43 | gevaerts | JdGordon: sure, that too. But if buffer_alloc() doesn't even tell them, then... |
| 11:05:47 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 11:05:51 | n1s | iirc the codecbuffer is at the end of the audiobuffer so if we alloc too much we could overwrite that |
| 11:06:20 | JdGordon | and also the order is close enough to random to causing problems... a bunch of non-essential buffers could be being allocated (and work) before a big essential buffer |
| 11:07:37 | n1s | that really has nothing to do with proper eror checking, but sounds like it needs a think-through |
| 11:08:11 | kugel | some parts don't even use buffer_alloc, but modify audiobuf directly |
| 11:08:18 | n1s | awesome |
| 11:08:40 | JdGordon | kugel: not after audio is init-ed though...? |
| 11:08:53 | kugel | no |
| 11:08:59 | bertrik | n1s, yes I meant some kind of canary value, plus maybe some extra info (block size) so we can parse the alloc buf |
| 11:09:33 | | Quit Spaceghost (Read error: Connection reset by peer) |
| 11:09:37 | gevaerts | Yes, we'd need to keep more information of course |
| 11:10:13 | | Join DerPapst [0] (~Alexander@p5797C710.dip.t-dialin.net) |
| 11:10:20 | JdGordon | bertrik: we could do that with logf just as easily though... if there is no protection then timestrecth+skin buffer could probably be naughty, should be just a matter of checking the audio buffer size int he debug screen though |
| 11:12:14 | pixelma | n1s: codecbuffer is unlikely because I see problems on my hwcodec target too |
| 11:12:19 | gevaerts | Except that logf isn't any good in official builds |
| 11:12:49 | JdGordon | of course, but that sounds like a waste in regular builds also |
| 11:13:17 | gevaerts | How many buffer_alloc()s does a regular running system do? |
| 11:13:51 | n1s | pixelma: ah |
| 11:13:59 | n1s | awesom |
| 11:14:00 | JdGordon | if audio playback works at all then it is almost certainly not the actuall alloc() which is causing problems |
| 11:14:18 | JdGordon | gevaerts: hundreds if dircache is enabled |
| 11:14:23 | gevaerts | right |
| 11:14:33 | gevaerts | We're talking about a few lines of code, and a few bytes (8? 16?) of metadata (length+magic value to check) in before and after each block I think |
| 11:14:35 | JdGordon | otherwsie I'd guess a dozen or so |
| 11:15:26 | gevaerts | Might still be a good idea to implement, even if it's not added to default builds |
| 11:15:55 | gevaerts | Even if the issues we're talking about now probably aren't related, some issues in the past have definitely been |
| 11:19:24 | JdGordon | *cough* proper buflib |
| 11:19:33 | bertrik | yeah, we could make this extra administration optional (#ifdef it) if people object to the few extra bytes it takes |
| 11:19:56 | bertrik | we could also store some kind of thread id with the blocks to know who allocated it |
| 11:20:30 | JdGordon | a string would be more useful, just about all would be on the main thread |
| 11:20:38 | bertrik | and have a debug screen with stats |
| 11:22:29 | gevaerts | I think having buffer_alloc() check if there's enough room and panic if not should be there |
| 11:22:54 | JdGordon | pixelma: check the info screen, whats the audio buffer size say? |
| 11:23:01 | gevaerts | Or return NULL and hope that callers check |
| 11:23:14 | | Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854]) |
| 11:23:22 | bertrik | gevaerts, yes that's a good start with very limited impact |
| 11:24:14 | kugel | JdGordon: IIRC dircache doesn't call buffer_alloc |
| 11:24:19 | * | JdGordon is charging his v1 clip to prove this isnt the problem |
| 11:24:22 | pixelma | JdGordon: audio buffer? |
| 11:24:34 | kugel | and not hundreds of times anyway |
| 11:24:51 | JdGordon | pixelma: the "Buffer" line |
| 11:24:53 | kugel | I think there're under 10 buffer_alloc calls in total |
| 11:25:37 | pixelma | JdGordon: on my Ondio? It says "1.22 MB", not sure what this is going to tell though |
| 11:26:17 | JdGordon | that says that buffer_alloc(0 isnt running out of room |
| 11:27:12 | JdGordon | $ find -iname "*.c" | xargs grep "buffer_alloc(" | wc -l -> 64 |
| 11:27:36 | bertrik | that also includes a lot of skin_buffer_alloc's I think |
| 11:28:26 | JdGordon | 36 |
| 11:28:59 | kugel | oh I was wrong, dircache buffer_allocs a lot |
| 11:33:01 | JdGordon | tagcache is also a big user |
| 11:33:10 | | Join Giova [0] (~giovanni@93.37.250.242) |
| 11:36:17 | Giova | JdGordon: Thanks for r28168, scrolling the menu via soft keys now working really good. |
| 11:36:30 | JdGordon | :) |
| 11:37:58 | Giova | but what about r28146? It looks terrible on my onda |
| 11:40:06 | Giova | scrolling the menu in absolute mode, made the selection bar disappear, maybe on Android it can be used, I don't like it on vx777 |
| 11:40:50 | kugel | I find showing a selection bar during scrolling looks terrible |
| 11:42:56 | Giova | :D |
| 11:43:37 | Giova | what about give to the user an option for that? |
| 11:44:15 | bertrik | gevaerts, n1s : something like this http://pastebin.com/bA4vFMUC ? |
| 11:44:20 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 11:44:49 | gevaerts | looks like a good start |
| 11:45:10 | JdGordon | but that isnt the problem! |
| 11:45:25 | JdGordon | and my damn clip isnt charging so i cant prove it :/ |
| 11:45:31 | gevaerts | JdGordon: who cares? :) |
| 11:45:41 | gevaerts | It might be a problem at some point! |
| 11:45:50 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 11:46:08 | kugel | bertrik: you could use %zu for size_t in format strings |
| 11:48:06 | kugel | maybe timestretch is overflowing its buffer |
| 11:48:26 | bluebrother | is there a reason rockboxdev.sh doesn't use −−disable-nls? |
| 11:48:30 | JdGordon | that sounds more likely |
| 11:48:35 | * | gevaerts is looking at adding overflow checking |
| 11:48:50 | gevaerts | bluebrother: n1s might object to that :) |
| 11:49:03 | gevaerts | Oh, *l* |
| 11:49:28 | bluebrother | gevaerts: he might have a problem with my mac then. I get binutils building only with −−disable-nls ;-) |
| 11:50:09 | bluebrother | but do we want localization for the cross compiler anyway? |
| 11:51:10 | | Quit Giova (Read error: Connection reset by peer) |
| 11:51:25 | *** | Saving seen data "./dancer.seen" |
| 11:52:50 | pixelma | JdGordon: I'm getting a "I09: CPUAdrEr"2 with r28168 on my Ondio with the "offending" theme, looking up the address after lunch |
| 11:53:17 | pixelma | a simpler one wrt nested conditionals works |
| 11:54:40 | gevaerts | Is there a reason why buffer_init() handleds the alignment, and not attributes or the linker? |
| 11:55:33 | | Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) |
| 11:57:14 | pixelma | JdGordon: seems to be in the scroll_engine |
| 11:57:32 | bluebrother | yay, eabi toolchain working on OS X 10.6 :) |
| 11:58:52 | * | bluebrother wonders if he should commit his changes to rockboxdev.sh or post a patch to get others try it first since he's using MacPorts quite a bit |
| 12:00 |
| 12:00:08 | | Join Giova [0] (~giovanni@93.37.250.242) |
| 12:01:35 | pixelma | bluebrother: there was someone in the forums a few days ago with MacOS 10.6, maybe you can ask there? |
| 12:01:51 | bluebrother | pixelma: yeah, that was the reason for looking into it again :) |
| 12:02:09 | bluebrother | guess I'll post a patch and post the id to that thread |
| 12:06:14 | gevaerts | Where is the code that checks for stack overflow? |
| 12:06:39 | gevaerts | ah, thread.c |
| 12:10:39 | | Join evilnick [0] (~Evilnick@rockbox/staff/evilnick) |
| 12:12:05 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 12:13:27 | gevaerts | bertrik: http://pastebin.com/S8NpcmGu |
| 12:13:35 | gevaerts | That still needs some #ifdefs |
| 12:13:45 | gevaerts | It's also untested |
| 12:15:00 | * | bertrik is looking at too many things at the same time |
| 12:15:06 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 12:15:09 | gevaerts | I think it doesn't just "waste" some memory, it's probably also too slow to enable all the time |
| 12:18:31 | gevaerts | Oh, and of course if an interrupt handler overwrites memory, it will blame the wrong thread |
| 12:18:49 | bertrik | clip+ with both tagcache and timestretch enabled fails in various strange ways |
| 12:19:23 | | Join Jerom [0] (~heidi@95.171.137.111) |
| 12:24:11 | JdGordon | does it fully boot though? |
| 12:25:11 | bertrik | it wouldn't boot with a microsd inserted |
| 12:29:42 | gevaerts | Yay, my patch makes my c250 not boot :) |
| 12:31:28 | JdGordon | don't thread switches need to be really *really* fast :D |
| 12:31:51 | gevaerts | yes, that's why this can't be enabled by defaukt |
| 12:32:06 | JdGordon | or apparently at all? :) |
| 12:32:09 | gevaerts | The not booting thing is that it claims buffer corruption |
| 12:32:30 | bertrik | gevaerts, on my clip+ I get a "tagcache corrupted buffer 300BC680 start" on boot :) |
| 12:32:44 | CIA-81 | New commit by kugel (r28169): Android: Exclude the main binary from make zip. |
| 12:33:01 | gevaerts | bertrik: yes, same symptoms :) |
| 12:33:04 | * | gevaerts looks into it |
| 12:33:15 | gevaerts | Maybe logf is better than panicf to get started |
| 12:33:46 | JdGordon | what needs to be done to add the sdl app to the build table? |
| 12:34:25 | CIA-81 | r28169 build result: All green |
| 12:38:06 | gevaerts | JdGordon: Zagor did some work on that recently. I suspect he may have a plan in mind |
| 12:38:11 | | Quit user890104 (Ping timeout: 272 seconds) |
| 12:39:01 | JdGordon | ok, I noticed android is in the table |
| 12:42:33 | | Join [sko] [0] (~sko]@p57A99021.dip0.t-ipconnect.de) |
| 12:43:02 | | Join teru [0] (~teru@KD059133117137.ppp.dion.ne.jp) |
| 12:43:03 | | Quit [sko] (Client Quit) |
| 12:43:30 | | Join [sko] [0] (~sko]@p57A99021.dip0.t-ipconnect.de) |
| 12:44:30 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 12:45:07 | gevaerts | hm, I can't remember now... |
| 12:45:14 | gevaerts | logf dumps are in reverse order, right? |
| 12:45:44 | gevaerts | no, they can't be |
| 12:47:25 | JdGordon | panic from audio_reset_buffer with svn... |
| 12:47:33 | JdGordon | OOM |
| 12:47:59 | JdGordon | how do i reset the settings on boot on the clip? |
| 12:50:40 | JdGordon | with timestrecth, cuesheet, lastfm all enabled i still have 800KB buffer |
| 12:50:55 | JdGordon | setting both limit settings to max crashes it thouhg |
| 12:51:13 | JdGordon | and database enabled also |
| 12:51:44 | kugel | http://pastie.org/1182280 <−− pixel accurate list scrolling |
| 12:51:49 | kugel | android builds updated |
| 12:51:53 | JdGordon | data abort starting playback though |
| 12:52:50 | soap | If I were to create a patch which /clearly/ will never be committed, yet wanted to share it with others who might find it useful, could I host it on FS, or should I host it on my site? |
| 12:53:43 | JdGordon | kugel: are you purposly reverting my first fix commit from a few hours ago with that diff? |
| 12:54:04 | JdGordon | removing the code under /* make sure it is inside the UI viewport */ |
| 12:54:06 | kugel | no, it's not reverted |
| 12:54:33 | kugel | action_get_touchscreen_press_in_vp() is called |
| 12:54:47 | JdGordon | ah right, my bad |
| 12:55:51 | bertrik | soap, I probably wouldn't mind having it on FS, if it's a kind of "research" patch for example |
| 12:56:41 | pixelma | recently I _sometimes_ get a "STKOV Main" on my M5 when skipping, going to file browser or changing volume or something like this from the WPS |
| 12:56:51 | kugel | soap: we only want patches on fs that seek inclusion |
| 12:56:58 | soap | Nothing that defensible. bertrik. |
| 12:57:21 | AlexP | soap: It has been said in the past that flyspray is just for things working towards being committed |
| 12:57:30 | AlexP | We've been closing those that never will be |
| 12:58:11 | teru | could anyone give me a comment about FS #6321? i'm not sure what to do about it. |
| 12:59:12 | AlexP | teru: I think a universal image viewer plugin would be a good thing |
| 12:59:25 | AlexP | Talk to wodz also, he has been working on a png viewer |
| 12:59:59 | kugel | teru: you don't need rb->cpucache_invalidate() if you use lc_open |
| 13:00 |
| 13:00:14 | AlexP | FS #11641 I think |
| 13:00:34 | gevaerts | bertrik: http://pastebin.com/sJWSFw1E |
| 13:00:43 | gevaerts | Define BUFFER_ALLOC_DEBUG to use it |
| 13:00:49 | AlexP | teru: Yeah, FS #11641 |
| 13:00:49 | pixelma | teru: are you the one recently working a lot on the text viewer? |
| 13:01:47 | teru | AlexP: thanks, i saw it. |
| 13:01:53 | AlexP | ok, cool |
| 13:02:08 | bertrik | gevaerts, I'll try it right away |
| 13:03:44 | JdGordon | kugel: not bad... its not using the full screen width apparently |
| 13:04:09 | kugel | what do you mean? |
| 13:04:26 | teru | kugel: I'll remove it then, thanks. |
| 13:04:29 | JdGordon | I dont think you actually compiled it for 480x800 :) |
| 13:05:18 | kugel | oh yes, 320x800 :\ |
| 13:05:54 | kugel | because tools/configure doesn't work properly |
| 13:06:44 | bertrik | gevaerts, it boots and plays OK with your patch and timestretch enabled |
| 13:07:00 | teru | pixelma: i think i don't touch the text viewer recently? |
| 13:07:28 | bertrik | when I also enable dircache, it still boots but I do see a WPS corruption |
| 13:08:00 | pixelma | teru: I didn't mean "recently" as "in the last week(s)" or so, more like "the latest changes to it were yours" |
| 13:09:11 | bertrik | gevaerts, never mind, I forgot the BUFFER_ALLOC_DEBUG |
| 13:11:15 | kugel | JdGordon: updated |
| 13:11:21 | JdGordon | ta |
| 13:12:29 | pixelma | teru: if so, I wondered about the blank line at the bottom even with page numbers turned off. It's wasteful on small displays |
| 13:12:59 | kugel | uchida worked on it |
| 13:13:35 | pixelma | yeah, I wasn't sure who it was (which is why I asked before) |
| 13:15:15 | JdGordon | android really does need the hardware buttons to work :/ |
| 13:15:36 | kugel | they should work, but they don't. the code is in svn |
| 13:16:34 | JdGordon | also kinetic scrolling |
| 13:16:40 | JdGordon | or whatever the heck its called |
| 13:16:47 | kugel | we're working on that :) |
| 13:17:00 | JdGordon | oh back button works |
| 13:17:10 | JdGordon | up/down does but not very often |
| 13:17:44 | JdGordon | hmm, not consistantly though :) |
| 13:22:23 | | Join utanapischti [0] (~username@df01ppp031.eplus-online.de) |
| 13:25:43 | kugel | JdGordon: like it yea? |
| 13:26:19 | | Quit sasquatch (Ping timeout: 272 seconds) |
| 13:26:22 | JdGordon | yeah |
| 13:27:17 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 13:27:29 | | Quit bmbl (Quit: Bye!) |
| 13:38:32 | | Join Staphylo [0] (~Bullet@AMontsouris-159-1-51-172.w92-128.abo.wanadoo.fr) |
| 13:39:29 | CIA-81 | New commit by bertrik (r28170): RDA5802 tuner: fix small bug in rda5802_init (writing too much data) |
| 13:39:53 | | Quit GeekShadow (Ping timeout: 252 seconds) |
| 13:40:30 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 13:41:25 | CIA-81 | r28170 build result: All green |
| 13:43:37 | CIA-81 | New commit by bluebrother (r28171): Improve some trace messages. |
| 13:45:30 | CIA-81 | r28171 build result: All green |
| 13:47:27 | | Quit teru (Ping timeout: 276 seconds) |
| 13:48:47 | | Join teru [0] (~teru@KD059133111160.ppp.dion.ne.jp) |
| 13:49:26 | amiconn | TheSeven: Hmm, where do we have CPU frequency changes from IRQ context? This can't be in general code, as then it would fail on coldfire |
| 13:51:26 | *** | Saving seen data "./dancer.seen" |
| 13:53:58 | | Nick bzed_ is now known as bzed (~bzed@devel.recluse.de) |
| 13:56:45 | bertrik | hmmm, now the WPS corruption problems on my clip+ seems to correlate with having tagcache enabled or not |
| 13:57:14 | | Join Lear [0] (chatzilla@rockbox/developer/lear) |
| 13:57:20 | | Join saratoga [0] (9803c22e@gateway/web/freenode/ip.152.3.194.46) |
| 13:57:22 | JdGordon | what sort of corruption? |
| 13:59:01 | CIA-81 | New commit by learman (r28172): Make sure get_lif_token_value isn't inlined, as it would defeat the purpose of introducing that function. E.g., gcc 3.4.6 for m68k is keen on inlining ... |
| 13:59:02 | bertrik | the outer part of the progress bar is not showing, only the filling part |
| 13:59:08 | TheSeven | amiconn: I don't know for sure where it came from, but something apparently called set_cpu_frequency from an IRQ handler |
| 13:59:33 | TheSeven | at least I ran into massive trouble when trying to access I2C (which uses IRQs itself) from there |
| 13:59:35 | bertrik | when it does show correctly, it seems as if the progress bar is written a few times, first without the outer part, then with the outer part |
| 14:00 |
| 14:00:18 | bertrik | the s5l8700 i2c drive rno longer works on the meizus |
| 14:00:39 | CIA-81 | r28172 build result: All green |
| 14:00:47 | amiconn | TheSeven: Well, on coldfirecpu_set_frequency can take up to 10ms (2ms typical) due to pll relock |
| 14:01:02 | TheSeven | bertrik: interesting... IIRC I reverted that to almost what you were doing before after the IRQ-based one caused trouble on the nanos |
| 14:01:09 | amiconn | Hence it must not be called from interrupt context |
| 14:01:10 | | Join _s1gma [0] (~d.d.derp@77.107.164.131) |
| 14:01:18 | JdGordon | bertrik: that's not what I'd call corruption, but ok |
| 14:01:25 | TheSeven | amiconn: wouldn't IRQs be locked out during a PLL relock anyway? |
| 14:01:33 | amiconn | No, why? |
| 14:01:51 | amiconn | The cpu is running at base clock during that time |
| 14:01:57 | TheSeven | ok |
| 14:02:06 | TheSeven | on the nano2g it might be running at like 32khz during that |
| 14:02:09 | amiconn | Locking out interrupts for such a long time would be bad |
| 14:02:24 | amiconn | Hmm, that may b e more problematic |
| 14:02:32 | amiconn | Coldfire base clock is 11.2896 MHz |
| 14:05:45 | CIA-81 | New commit by gevaerts (r28173): Add optional (define BUFFER_ALLOC_DEBUG to enable it) code to check for code overflowing buffer_alloc()-allocated buffers. ... |
| 14:06:27 | | Quit MethoS- (Remote host closed the connection) |
| 14:07:31 | saratoga | gevaerts: you should accidentally enable that in an SVN build for a week or so and see how many people report panics ;) |
| 14:08:00 | CIA-81 | r28173 build result: All green |
| 14:08:02 | kugel | the panic is enabled as I see it |
| 14:09:03 | | Quit ender` (Quit: Little expense had been spared to create the impression that no expense had been spared.) |
| 14:09:04 | saratoga | only if BUFFER_ALLOC_DEBUG is enabled? |
| 14:09:17 | | Quit [sko] (Quit: Leaving.) |
| 14:09:20 | gevaerts | The panic that checks if there's enough room is always enabled |
| 14:09:31 | n1s | that's good imo |
| 14:09:43 | JdGordon | gevaerts: can you play with macros and get the calling function/line into the buffer header? I'll whip up a nice debug screen if you do :) |
| 14:09:50 | gevaerts | The extra metadata, buffer guards, and code that walks the buffers to check for overflow at every thread switch isn't |
| 14:10:16 | gevaerts | JdGordon: That would be nice, but it's tricky... |
| 14:10:27 | gevaerts | As in, I have no idea how to do it :) |
| 14:10:32 | JdGordon | it really doesnt need to check every thread switch, really only when coming off the main thread |
| 14:11:29 | gevaerts | Maybe, but even then I think it's too expensive for a regular build |
| 14:12:00 | | Join [sko] [0] (~sko]@p57A99021.dip0.t-ipconnect.de) |
| 14:12:46 | gevaerts | The way I see it, this is something you enable whenever you're hunting a bug with interesting effects |
| 14:13:18 | * | JdGordon would also like to use host malloc instead of buffer_alloc() for app builds to not need to reboot to enable stuff |
| 14:13:43 | gevaerts | Yes, that would make sense |
| 14:13:58 | gevaerts | And easy to do, actually |
| 14:14:07 | JdGordon | especially when it is pretty much impossible to reboot the android app currently |
| 14:14:12 | gevaerts | Just call malloc() from buffer_alloc() |
| 14:14:33 | JdGordon | well yes, but that doesnt make the settings magically start working :) |
| 14:14:41 | kugel | gevaerts: and who fixes the calling code that expects the need to reboot? |
| 14:15:01 | gevaerts | kugel: yes, but JdGordon didn't ask for that :) |
| 14:15:35 | JdGordon | Also, it would be nice if we came up with a good way to do host integration for things that arnt possible on DAPs... i.e last.fm logging and AA downloading |
| 14:17:04 | gevaerts | What is the block starting at dircache.c line 534 trying to do? |
| 14:17:25 | * | JdGordon likes guessing games :) |
| 14:18:36 | TheSeven | bertrik: do you have any idea what could have made I2C fail on meizu? |
| 14:18:45 | gevaerts | oh, I think I see... |
| 14:19:12 | TheSeven | as I said, I reverted most of my changes (and used the polling version again) after we had some trouble with I2C interrupts getting lost on the nano2g |
| 14:19:15 | JdGordon | gevaerts: I think those targets actually save the dircache cache as a file so it doesnt need to rescan |
| 14:19:18 | bertrik | TheSeven, no, I just reverted to an earlier version to make it work again |
| 14:19:38 | JdGordon | so that makes sure the file actually has a chance of being usable because the pointer is the same as last boot? |
| 14:19:43 | gevaerts | JdGordon: yes, and this code checks if it would be loaded at the same address |
| 14:19:54 | bertrik | the meizus are not even close to normal rockbox use, so don't worry to much about it |
| 14:20:11 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 14:20:21 | TheSeven | nevertheless I'd like to know *why* it breaks, as this doesn't seem to work 100% right on nano2g either |
| 14:20:23 | | Join wodz [0] (~wodz@chello087206240131.chello.pl) |
| 14:20:43 | JdGordon | by the way, IIRC pondlife made a patch ages ago to panic if anything called buffer_alloc after audio was initialsed, might be worth looking at with this fiddling |
| 14:20:43 | gevaerts | JdGordon: that will break (as in, throw away the file every time) with BUFFER_ALLOC_DEBUG defined |
| 14:20:58 | gevaerts | Unless I add a 0-size check |
| 14:21:12 | JdGordon | probably not a big deal |
| 14:21:14 | wodz | amiconn: ping |
| 14:21:46 | TheSeven | bertrik: if I use the interrupt-based driver, it locks up when doing things like changing volume, while the interrupt-based driver I use in emBIOS seems to work just fine, even though it isn't used heavily |
| 14:22:25 | TheSeven | interestingly I can't remember seeing it lock up when switching the backlight on or off, so it might be somehow related to the codec which I'm not using at all in emBIOS |
| 14:22:48 | gevaerts | maybe not. On the other hand, adding this check (only in the debug case anyway...) isn't much work either... |
| 14:23:01 | amiconn | gnip |
| 14:23:35 | bertrik | TheSeven, maybe we're really losing interrupts somewhere, or incorrectly clearing them |
| 14:23:45 | | Join s1gma_ [0] (~d.d.derp@77.107.164.131) |
| 14:24:33 | TheSeven | it happened reproducibly when changing volume, but apparently the backlight was working fine |
| 14:24:49 | JdGordon | OK, I'm looking at doing host malloc... is there any point doing the eisting buffer alloc if malloc() returns NULL? |
| 14:25:49 | | Quit _s1gma (Ping timeout: 240 seconds) |
| 14:25:50 | | Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 14:26:50 | wodz | amiconn: greylib uses 129 shades - does it means that the input value should be within the bounds or 0-255 is rescaled internally? |
| 14:27:05 | amiconn | The latter |
| 14:27:32 | wodz | and 0 is white right? |
| 14:27:37 | amiconn | nope |
| 14:27:41 | amiconn | Input is plain standard 8 bit greyscale data. |
| 14:27:44 | CIA-81 | New commit by gevaerts (r28174): If BUFFER_ALLOC_DEBUG is defined, make buffer_alloc() not actually allocate anything if size==0, so code that uses buffer_alloc(0) to find out what ... |
| 14:28:20 | amiconn | The greylib applies gamma adjustment, lcd linearity adjustment, and rescales to 0..128 |
| 14:29:11 | CIA-81 | r28174 build result: All green |
| 14:29:19 | amiconn | It also handles necessary white<->black flipping, even dynamically on iPod G1/G2 |
| 14:29:28 | | Quit liar (Ping timeout: 264 seconds) |
| 14:29:29 | wodz | ? |
| 14:29:30 | JdGordon | haha! simply putting the malloc() call into buffer_alloc() made the sdl app segfault! |
| 14:29:39 | JdGordon | we may just have a problem here! |
| 14:29:59 | amiconn | The iPod G1/G2 LCD is inverted when backlight is on |
| 14:30:15 | gevaerts | kugel: the easy way to "fix" that would be to just always allocate at boot (without checking the setting), and hope that the OS we use does lazy allocation |
| 14:30:30 | gevaerts | JdGordon: any backtrace? |
| 14:30:33 | JdGordon | is 0xfffffffff08f1010 a probable usable retval from malloc? |
| 14:30:38 | JdGordon | 64bit os obviously |
| 14:31:31 | kugel | gevaerts: I'm not convinced that's an easy way :) |
| 14:31:42 | wodz | amiconn: can I assume that background in greylib is 255? |
| 14:31:58 | gevaerts | JdGordon: I get very different pointers in a trivial test program |
| 14:32:06 | amiconn | wodz: Assume in what context? |
| 14:32:19 | gevaerts | JdGordon: what OS is this? |
| 14:32:43 | JdGordon | linux, and yeah something is not right (This might actually be a real skin bug!) |
| 14:32:55 | wodz | amiconn: I want to support transparency in png to some degree so I have to know what is background |
| 14:33:00 | JdGordon | malloc is returning sane values but skin_alloc_element() is breaking |
| 14:33:54 | gevaerts | Something storing pointers in a type that can't handle them? |
| 14:34:06 | JdGordon | 1320960, 0xfffffffff08f1010 alloced that looks odd... all the other allocs are in 0x122d4c0 area |
| 14:34:31 | amiconn | Default background (after grey_init() ) is white (255). It can be changed and queried as with any other implementation of the rockbox gfx api |
| 14:34:45 | | Join _s1gma [0] (~d.d.derp@77.107.164.131) |
| 14:34:46 | amiconn | grey_set_background() / grey_get_background() |
| 14:35:07 | JdGordon | 1080 retval->type = UNKNOWN; |
| 14:35:07 | | Join notlistening [0] (~tom@94-195-105-95.zone9.bethere.co.uk) |
| 14:35:08 | JdGordon | (gdb) p retval |
| 14:35:08 | JdGordon | $1 = (struct skin_element *) 0xfffffffff08f1010 |
| 14:35:39 | | Quit s1gma_ (Ping timeout: 255 seconds) |
| 14:36:26 | gevaerts | JdGordon: no segfault here |
| 14:36:38 | amiconn | Of course this won't help if there's a backdrop, but fortunately (in this case) the greylib doesn't support backdrops |
| 14:36:52 | notlistening | kugel do you want bugs reporting on the andoid app..? |
| 14:36:55 | JdGordon | gevaerts: 64bit os? |
| 14:37:03 | gevaerts | JdGordon: yes, but a sim, not the app |
| 14:37:07 | kugel | notlistening: no |
| 14:37:16 | notlistening | ok ;) |
| 14:37:36 | kugel | you can mention them here if you want, if you're lucky someone will do something about it, but not on flyspray please |
| 14:37:48 | JdGordon | unsigned char* should be safe no? |
| 14:38:29 | JdGordon | buffer_front = (void *)(((unsigned long)buffer_front + 3) & ~3); <- not entirely safe? |
| 14:39:08 | amiconn | no |
| 14:39:17 | gevaerts | intptr_t sounds better |
| 14:39:30 | amiconn | 'long' isn't guaranteed to be large enough to hold a pointer |
| 14:39:51 | amiconn | On linux x86_64 it should work though, but it will break on win64 |
| 14:39:53 | JdGordon | I dot think that is the problem though, that would cause the crash the 2nd time not first time, I'll fix it anyway |
| 14:39:56 | bertrik | is the cast to unsigned long (or anything else) really needed anyway? |
| 14:40:16 | amiconn | Yes |
| 14:40:40 | amiconn | Ever tried logical operations on pointers? The compiler doesn't allow this |
| 14:40:44 | JdGordon | yeah, that wasnt it |
| 14:40:50 | notlistening | kugel I will try and get some useful information that will help out more than just it stops playing :D |
| 14:43:10 | bertrik | amiconn, ah ok, I was confused because it seemed as if the cast was needed to do +3 |
| 14:43:19 | | Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) |
| 14:43:22 | kugel | JdGordon: do you call malloc for each skin element or do you obtain the buffer with a single big malloc? |
| 14:43:32 | JdGordon | single buffer still |
| 14:43:49 | JdGordon | (that will eventually be changed also, but one thing at a time) |
| 14:44:15 | amiconn | Well, you could cast outside the inner ( ), but if you do this with anything else than [unsigned] char* you will confuse people, probably even yourself |
| 14:44:31 | kugel | single buffer is probably easier (also we don't need to drift away too much from dap-rockbox), unless you want to mess with freeing all elements |
| 14:44:59 | bertrik | amiconn, no, that would not confuse me at least :) |
| 14:45:00 | amiconn | (also void* when using gcc - other compilers don't allow pointer arithmetics on void*) |
| 14:45:05 | JdGordon | that code is there already, but yes, its low on the priorities |
| 14:47:28 | | Quit _s1gma (Ping timeout: 264 seconds) |
| 14:47:43 | | Join _s1gma [0] (~d.d.derp@77.107.164.131) |
| 14:48:10 | n1s | don't we have a macro for aligning pointers? |
| 14:48:22 | gevaerts | JdGordon: did you include stdlib.h? |
| 14:48:55 | gevaerts | If not, C assumes that a function returns int, which messes with the pointer that malloc() returns |
| 14:49:17 | JdGordon | good call :) |
| 14:49:42 | JdGordon | 1320960, 0x7ffff08f1010 alloced <- still a wierd looking region, but ok :) |
| 14:50:32 | kugel | JdGordon: btw, I think you should fix up size, not the pointer |
| 14:50:43 | JdGordon | ? |
| 14:50:45 | gevaerts | Yes, I was going to suggest that too |
| 14:50:48 | bertrik | yeah, I wondered about that too in buffer.c |
| 14:51:15 | gevaerts | If you round the size up, the pointer will stay aligned |
| 14:51:25 | gevaerts | And size is never that big, so you're fine by definition :) |
| 14:51:36 | JdGordon | not my code :) |
| 14:51:47 | gevaerts | I actually changed that in buffer.c |
| 14:52:10 | kugel | JdGordon: really? I seem to remember the same lines in the old skin engine :) |
| 14:52:17 | kugel | before bieber :) |
| 14:52:24 | JdGordon | that line copy+paste from buffer.c |
| 14:52:37 | gevaerts | buffer.c doesn't do that! |
| 14:52:46 | JdGordon | it did when I copied it :p |
| 14:52:52 | gevaerts | (since a half an hour or so anyway) |
| 14:52:52 | JdGordon | I'll change that now |
| 14:56:05 | CIA-81 | New commit by jdgordon (r28175): fiddle with the alloc requested size instead of the buffer pointer to keep the buffer 32bit aligned |
| 14:56:41 | teru | (FS #6321) I want opinion about "exclude entries from viewers.config for the targets which does not support that file type". currently, it is png for non-color targets. |
| 14:57:07 | | Quit notlistening (Remote host closed the connection) |
| 14:57:27 | gevaerts | JdGordon: you'll have more fun. Try to find out why dircache.c messes with audiobuf directly... |
| 14:57:34 | wodz | teru: png support is on the way |
| 14:57:49 | CIA-81 | r28175 build result: All green |
| 14:57:53 | n1s | teru: sounds like a good idea |
| 14:57:54 | JdGordon | gevaerts: oh SHIT! you serious? :'( |
| 14:58:04 | gevaerts | JdGordon: that's what it looks like anyway |
| 14:58:12 | bertrik | teru, png can also be greyscale, right? |
| 14:58:16 | n1s | surely there are other filetypes not supported on all targets |
| 14:58:45 | gevaerts | rolo too, but I don't think that matters much here |
| 14:58:56 | AlexP | Give wodz a few minutes and png will be on greyscale too :) |
| 14:59:14 | JdGordon | we can disable dircache on hosted though :) |
| 14:59:14 | teru | wodz: yeah, nice work. but same situation could happen in the future. for example when someone add gif viewer only for color target. |
| 14:59:24 | gevaerts | ah, good call :) |
| 14:59:30 | gevaerts | We probably should, anyway |
| 14:59:37 | gevaerts | If it's not already |
| 14:59:37 | kugel | AlexP: actually, I think he managed greyscale already and is now adding greylib support (i.e. even nicer :) ) |
| 14:59:51 | kugel | it is disabled |
| 15:00 |
| 15:00:04 | gevaerts | ok |
| 15:00:48 | AlexP | kugel: Yeah, it already works |
| 15:00:57 | gevaerts | JdGordon: ok, dircache is fine. Now fix tagcache.c which does that too :) |
| 15:00:59 | AlexP | I was using it last night :) |
| 15:01:15 | kugel | the host does caching, and it's not reasonable to cache the entire filesystem on a real machine |
| 15:01:43 | kugel | ignoring the general breakage with recursive symlinks :) |
| 15:02:09 | JdGordon | arg, tagcache is sort of needed though |
| 15:02:31 | kugel | tagcache works as far as I can tell |
| 15:03:19 | gevaerts | kugel: yes, but you didn't rip out buffer_alloc() :) |
| 15:03:31 | gevaerts | JdGordon: looks like an easy fix there though |
| 15:05:47 | n1s | btw, having the properties plugin in the viewers list makes no sense |
| 15:07:27 | JdGordon | gevaerts: did you change dircache.c to not be naughty? |
| 15:07:33 | gevaerts | no |
| 15:07:42 | gevaerts | If it's disabled anyway, who cares? |
| 15:08:06 | JdGordon | Ideally nothing should use audiobuf directly |
| 15:08:31 | gevaerts | I'm trying to find out why that tagcache audiobuf abuse is safe (I assume it is, there aren't enough crash reports for it not to be...) |
| 15:08:55 | JdGordon | because it happens early probably? /me hasnt had a look yet |
| 15:09:17 | gevaerts | That's what I'm looking for. From what I can see, it can happen at any time... |
| 15:09:58 | Giova | JdGordon: One of the latest build has fixed the bug #11626 |
| 15:10:11 | JdGordon | goody |
| 15:10:17 | JdGordon | (to both above messages :p ) |
| 15:11:45 | teru | n1s: I'm not sure how to implement the idea. in my patch, image file types are associated to imageviewer.rock and imageviewer is build for all bitmap targets. so all image file types are included to viewers.config and it causes the issue. |
| 15:11:47 | Lear | gevaerts: Only during tagcache init, as far as I can see... |
| 15:12:04 | n1s | teru: aha |
| 15:12:11 | gevaerts | Lear: oh, right |
| 15:12:28 | JdGordon | yeah 4417 seems scary, but probably safe? untill we get preemtive scheduling |
| 15:12:29 | * | gevaerts missed the #ifdef __PCTOOL__ |
| 15:13:23 | n1s | but tagcache.c should call buffer_alloc and not do this directly anyway, right? |
| 15:13:24 | gevaerts | I assume commit() does file IO, which could yield as far as I know |
| 15:13:43 | kugel | teru: just preproces viewers.config? |
| 15:14:11 | gevaerts | oh, and it sleeps, which definitely yields |
| 15:14:48 | * | TheSeven knows why he doesn't like cooperative multitasking |
| 15:14:49 | gevaerts | So yes, that bit could well be responsible for weird hard to reproduce issies |
| 15:14:55 | Lear | gevaerts: But the main thread waits for the initialized flag or something to be set (hence the "in foreground" comment). |
| 15:15:07 | gevaerts | Lear: but do other threads? |
| 15:15:21 | gevaerts | Well, other threads shouldn't be buffer_alloc()ing anyway I guess |
| 15:16:27 | JdGordon | the buffer isnt required after the commit so there must be a better way to do this |
| 15:16:40 | JdGordon | which would also mean not neeing a reboot to commit |
| 15:17:12 | gevaerts | It could steal the plugin buffer :) |
| 15:17:38 | JdGordon | any ideas how much it needs? |
| 15:17:40 | * | gevaerts finds dircache_steal_buffer()... |
| 15:18:23 | gevaerts | It grabs the entire audio buffer basically |
| 15:18:39 | kugel | JdGordon: it needs exactly 32*1024*1024 |
| 15:18:53 | gevaerts | kugel: only if __PCTOOL__ is defined :) |
| 15:18:56 | kugel | oh, that's the pctool case |
| 15:19:06 | gevaerts | So it's "safe" in the sense that no other allocations can mess up its idea of the world |
| 15:19:17 | kugel | well, I stronly suspect it won't need more on the dap |
| 15:19:17 | n1s | 32MB would be kind of hard on most targets ;) |
| 15:19:44 | kugel | err, that's 32*M*B, oops (/me thought K) |
| 15:21:36 | * | JdGordon notes there is no locking on the plugin buffer also |
| 15:23:05 | n1s | that's why it's so much fun hunting bugs, you usually dig up a whole bunch of bad things... |
| 15:23:06 | kugel | that tempbuf code is strongly suspicious in any way |
| 15:23:21 | kugel | what if the audio buffer isn't big enough? it could overwrite codec or plugin buffer |
| 15:24:05 | JdGordon | I'm replacing it with plugin_get_buffer() and removing the dircache steal |
| 15:25:02 | kugel | hopefully it won't clash with skin engine which also uses the plugin buffer? |
| 15:25:18 | gevaerts | JdGordon: that may well be too small... |
| 15:25:30 | * | gevaerts doesn't like that code either |
| 15:25:53 | JdGordon | kugel: Lear said the main thread waits for init so it should be safe, but yes a proper fix is also needed |
| 15:25:55 | * | TheSeven suggests just throwing everything away and rewriting it from scratch |
| 15:26:17 | JdGordon | gevaerts: I'm working on the assumption that it doesnt care how much it has, but the more the merrier |
| 15:26:17 | kugel | I see calls to the strange code from the tagcache thread so it's not only at init |
| 15:26:52 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 15:27:19 | | Quit BlakeJohnson86 (Read error: Connection reset by peer) |
| 15:27:40 | JdGordon | which strange code? |
| 15:27:44 | n1s | JdGordon: the size is checked in tagcache.c:2435 and it bails out if there is too little buffer left |
| 15:27:48 | | Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 15:28:43 | kugel | JdGordon: the tempbuf allocation one |
| 15:28:49 | n1s | the build_index comment seems to be lying, returning 0 or < 0 has the same result |
| 15:29:11 | n1s | ah, no it doesn't i can't read |
| 15:31:25 | n1s | hmm, or well, the only difference is that the commit_delayed field is set which is only checked in one place and results in a "reboot please" splash and nothing else afaics |
| 15:32:17 | gevaerts | Can't we make the bootloader commit the database? That would fix everything! |
| 15:32:18 | * | gevaerts hides |
| 15:33:08 | | Join domonoky1 [0] (~Domonoky@agsb-d9bdb647.pool.mediaWays.net) |
| 15:33:08 | | Quit Horscht (Ping timeout: 240 seconds) |
| 15:33:45 | | Quit domonoky (Ping timeout: 252 seconds) |
| 15:34:54 | n1s | for some things it would be nice to be able to alloc a largeish buffer for a short time and then free it again, we need a proper malloc! |
| 15:35:07 | n1s | with special magic of course |
| 15:35:50 | | Join FlynDice [0] (~FlynDice@64.134.138.92) |
| 15:36:02 | gevaerts | We could have a buffer_borrow() function with a mutex so buffer_alloc() will block until buffer_return() is called |
| 15:36:03 | n1s | so it would primarily evict the already consumed data in the audio buffer and if that wasn't enough the data furthest in the future and else, fail |
| 15:36:33 | kugel | gevaerts: that's not a bad idea |
| 15:37:20 | gevaerts | It would handle this case anyway |
| 15:38:32 | JdGordon | and using that for the actual audio buffer would make things a bit safe also |
| 15:39:27 | | Quit n1s (Quit: Lämnar) |
| 15:39:45 | gevaerts | Or for USB |
| 15:40:32 | * | TheSeven just found something in the nano2g that looks suspiciously like memory2memory dma |
| 15:40:35 | gevaerts | Although that would need more work I guess |
| 15:40:42 | | Join Horscht [0] (~Horscht@p4FD4E4E4.dip.t-dialin.net) |
| 15:40:42 | | Quit Horscht (Changing host) |
| 15:40:42 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 15:41:20 | | Quit GeekShadow (Ping timeout: 240 seconds) |
| 15:42:35 | TheSeven | nano2g OF* |
| 15:42:45 | gevaerts | Basically unify audio_get_buffer() and buffer_alloc() a bit |
| 15:44:09 | JdGordon | and to overengineer it, allow it to be non-blocking (so fail if it cant get the buffer) and requested_size so more than one thing can borrow a block |
| 15:44:37 | gevaerts | Wouldn't you get fragmentation then? |
| 15:44:47 | TheSeven | JdGordon: What about just implementing a proper malloc? |
| 15:44:58 | JdGordon | well that would be the obvious solution :p |
| 15:45:07 | gevaerts | How? No MMU, remember... |
| 15:45:13 | JdGordon | buflib |
| 15:45:22 | gevaerts | i.e. you can implement malloc(), but it won't work well |
| 15:45:32 | TheSeven | the aim should of course be to make sure that nothing stays allocated for too long |
| 15:46:07 | JdGordon | the requested_sie thing was me being silly, but not blocking would be useful |
| 15:46:26 | TheSeven | the audio buffer should just float around in the empty space |
| 15:46:51 | Jaykay | rockbox does work with sdhc cards of all sizes, right? (i plan to buy a 8gb one) |
| 15:46:55 | Jaykay | e200v1 |
| 15:47:00 | gevaerts | JdGordon: for cases like doing whatever you need to do, or splash for audio stop or reboot, you mean? |
| 15:47:29 | JdGordon | or trying other potential buffers like the plugin buffer if audio one isnt available |
| 15:47:39 | JdGordon | which would be unlikely if this isnt abused |
| 15:48:00 | TheSeven | actually I'd like to get rid of the plugin buffer as well :D |
| 15:48:06 | JdGordon | Jaykay: yes |
| 15:48:12 | Jaykay | ok, thanks :) |
| 15:48:44 | gevaerts | I wouldn't mind seeing the buflib system that was once proposed, and position-independent plugins |
| 15:48:50 | TheSeven | or we could at least use the plugin buffer for audio cache as long as no plugin is running |
| 15:49:08 | gevaerts | That doesn't mean we can't improve things a bit now though :) |
| 15:49:33 | * | FlynDice finishes 30 minutes furiously searching for prebuilt android .apk availability before deciding to punt and request handy link from someone smarter here.... |
| 15:50:09 | kugel | http://www.rockbox.org/wiki/AndroidPort :) |
| 15:51:01 | FlynDice | kugel: Thanks, of course I coulda rolled my own by this time... |
| 15:51:28 | *** | Saving seen data "./dancer.seen" |
| 15:51:43 | bertrik | Does anyone here have a nano 1g and an ipod fm remote? |
| 15:52:28 | | Quit BlakeJohnson86 (Read error: Connection reset by peer) |
| 15:58:15 | Jaykay | wiki SansaE200Port : "Flash driver DONE - This can be substantially improved by using DMA and sleeping/yielding appropriately" and "Not all plugins have been adapted to the Sansa's screen layout yet." Are these still valid? |
| 16:00 |
| 16:00:06 | FlynDice | kugel: Is the AndroidPort hidden on the wiki main page on purpose or has it just not been added yet? |
| 16:00:22 | JdGordon | well replacing those nasty allocs in tagcache with plugin_get_buffer works |
| 16:01:24 | gevaerts | JdGordon: with big databases? |
| 16:01:36 | JdGordon | 3000+ files, e200 sim |
| 16:01:57 | JdGordon | if it works on target is another story |
| 16:02:23 | gevaerts | I doubt if it will work with 50000+ files |
| 16:03:11 | kugel | FlynDice: no special reason |
| 16:03:56 | FlynDice | Ok, I'll try to add it. |
| 16:04:43 | gevaerts | hm, does the database actually work with large amounts of files on Archoses, or the 2MB clips? |
| 16:05:14 | JdGordon | gevaerts: in that case it would be nice if someone reworked it so work with smaller buffers\ |
| 16:06:26 | JdGordon | I'm not entirely sure buffer_borrow() would solve tagcaches nasty allocing anyway |
| 16:09:35 | gevaerts | Could someone who has a Clip (and can find it...) try putting lots of files on it (e.g. the HVSC), and see if it can initialise the dayabase with that? |
| 16:09:40 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 16:11:05 | JdGordon | could someone make a legal mp3/whatever with no audio and a script to copy it 100000 times? |
| 16:11:23 | gevaerts | JdGordon: just use the HVSC :) |
| 16:14:57 | | Quit fdinel (Read error: Connection reset by peer) |
| 16:16:45 | | Quit GeekShadow (Ping timeout: 240 seconds) |
| 16:22:23 | kugel | FlynDice: write just AndroidPort, the wiki software recognizes it as a wiki word and makes the link |
| 16:22:38 | kugel | :) |
| 16:22:45 | FlynDice | thanks... |
| 16:26:03 | FlynDice | Seems I always have to make things way too complicated.... |
| 16:29:04 | | Quit PaulJam (Ping timeout: 255 seconds) |
| 16:31:13 | | Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854]) |
| 16:37:20 | | Join Evilnick_ [0] (~Evilnick@cpe-24-193-43-185.nyc.res.rr.com) |
| 16:38:53 | | Join Evilnick__ [0] (~Evilnick@cpe-24-193-43-185.nyc.res.rr.com) |
| 16:40:30 | | Quit evilnick (Ping timeout: 240 seconds) |
| 16:41:51 | | Quit Evilnick_ (Ping timeout: 252 seconds) |
| 16:52:33 | | Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 16:53:15 | | Join Nausicaa [0] (~Nausicaa@c-71-239-58-153.hsd1.il.comcast.net) |
| 16:55:29 | | Quit tchan (Quit: WeeChat 0.3.3-dev) |
| 16:55:46 | wodz | ehh simple transparency mode of PNG is a pain in 16bit depth |
| 16:56:26 | | Join clone4crw [0] (~calvin@97-86-227-168.dhcp.roch.mn.charter.com) |
| 16:56:56 | | Quit clone4crw (Remote host closed the connection) |
| 17:00 |
| 17:01:37 | | Quit teru (Quit: Quit) |
| 17:01:46 | | Join clone4crw [0] (~calvin@97-86-227-168.dhcp.roch.mn.charter.com) |
| 17:06:56 | | Quit [sko] (Quit: Leaving.) |
| 17:07:33 | | Quit Jerom (Read error: Connection reset by peer) |
| 17:08:20 | | Join Jerom [0] (~jerome@95.171.137.111) |
| 17:10:46 | | Quit JdGordon (Ping timeout: 276 seconds) |
| 17:28:08 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 17:30:00 | | Join mirak_ [0] (~mirak@81-64-223-104.rev.numericable.fr) |
| 17:40:25 | | Quit edboyer93 () |
| 17:41:40 | | Join webguest45 [0] (~4f466137@giant.haxx.se) |
| 17:41:50 | | Quit webguest45 (Client Quit) |
| 17:42:23 | wodz | how fancy should be our png decoder? I think we should support all color modes (including alpha channel). But what to do with 1)simple transparency 2) background chunk? This two adds much complexity to decoder |
| 17:44:38 | pixelma | wodz: did you try at least try compiling of the imageviewer (with the greylib png support) for sh with the small plugin buffer? |
| 17:45:16 | wodz | nop |
| 17:51:30 | *** | Saving seen data "./dancer.seen" |
| 17:52:27 | wodz | pixelma - it compiles for ondioFM 2MB |
| 17:53:26 | | Quit mirak_ (Read error: Connection reset by peer) |
| 17:54:41 | wodz | small png files works ok in ondioFM sim (2MB) |
| 17:54:43 | | Join mirak_ [0] (~mirak@81-64-223-104.rev.numericable.fr) |
| 17:58:09 | | Join jimbo [0] (hakz@78-105-232-3.zone3.bethere.co.uk) |
| 17:59:56 | jimbo | hey guys, had the error message about the arm-elf-eabi-gcc command not found, ran rockboxdev.sh to download it |
| 18:00 |
| 18:00:04 | jimbo | how long will that take to complete? |
| 18:00:25 | gevaerts | jimbo: that depends on your system |
| 18:00:46 | jimbo | running vmware |
| 18:01:14 | jimbo | but my system is a dual core 2ghz, with 4gb ram |
| 18:01:24 | gevaerts | It takes about 15 minutes on my laptop running linux, up to ten hours or so on cygwin on older systems |
| 18:01:27 | jimbo | i'm seeing a ton of text |
| 18:01:34 | jimbo | its scrolling too fast to read any of it |
| 18:01:41 | gevaerts | That's good :) |
| 18:01:50 | gevaerts | I'd say half an hour or so |
| 18:01:52 | jimbo | ok |
| 18:02:08 | | Join s1gma_ [0] (~d.d.derp@77.107.164.131) |
| 18:05:15 | | Quit _s1gma (Ping timeout: 240 seconds) |
| 18:05:37 | bluebrother | jimbo: rockboxdev.sh doesn't download the compiler. It download its source and compiles it, which is why it takes a notable time to finish. |
| 18:10:19 | jimbo | ok |
| 18:11:00 | jimbo | i'm trying to compile now, it says that this client is too old to work with working copy |
| 18:11:19 | jimbo | pleae download new subversion or something |
| 18:11:26 | | Quit s1gma_ (Quit: Leaving) |
| 18:11:50 | jimbo | now it seems to be compiling it |
| 18:12:04 | jimbo | getting lots of warnings, etc |
| 18:12:16 | bluebrother | how did you check out the Rockbox source? This indicates that you checked out with a different (i.e. newer) client than you have running right now |
| 18:12:34 | jimbo | i used svn to download it this morning |
| 18:12:55 | jimbo | ran a patch on it, which seemed to work |
| 18:13:08 | bluebrother | well, but how? If you see this message then you definitely used a different version of svn (or a different client) when checking out |
| 18:13:13 | | Join _s1gma [0] (~d.d.derp@77.107.164.131) |
| 18:13:31 | bluebrother | patching the sources won't make a difference here. |
| 18:14:15 | jimbo | well when I got that error message I ran rockboxdev and entered just "e" when asked what flag to use |
| 18:14:23 | * | amiconn suspects that *writing* to 0x0.... area on PP actually writes to IRAM as well |
| 18:14:30 | jimbo | it did its thing, and now i'm building |
| 18:14:39 | * | amiconn will test this theory soon |
| 18:14:45 | bluebrother | rockboxdev.sh doesn't use svn at all |
| 18:15:06 | jimbo | then i'm not sure whats wrong :S |
| 18:15:18 | jimbo | its still doing smoething though |
| 18:16:10 | jimbo | i'll let it continue and see where i'm at |
| 18:16:21 | amiconn | Hmm, or maybe not |
| 18:20:32 | jimbo | yep got the subversion error again so i'm guessing it didn't work |
| 18:20:40 | jimbo | should i get teh source again and start from scratch? |
| 18:24:53 | jimbo | how did I get an older svn then? |
| 18:25:01 | jimbo | is there a way to upgrade it? |
| 18:25:04 | TheSeven | svn up -r whatever |
| 18:30:01 | pixelma | wodz: I don't think sim tells much there, I think I'm going to try. What was the FS# again? |
| 18:32:00 | wodz | FS #11641 - try v1 patch |
| 18:32:09 | jimbo | inside the rockbox directory, typed in svn up, it said this client is too old... |
| 18:32:19 | TheSeven | aha |
| 18:32:31 | jimbo | this client is too old to work with working copy '.' |
| 18:32:43 | wodz | sim tells something - bigger images don't load with error of out of memory from decoder |
| 18:32:55 | TheSeven | so you're using a working copy that has already been touched by a newer svn client with an older client |
| 18:33:06 | TheSeven | there was an incompatible working copy format change some time ago |
| 18:33:34 | TheSeven | either re-checkout it completely and don't touch it with newer SVN clients any more, or update *all* of your svn clients that might touch it |
| 18:34:30 | pixelma | wodz: was there something to pay attention with svn? |
| 18:36:18 | wodz | pixelma: ah yes v1 patch do not apply cleanly to svn checkout ($id$ issue) |
| 18:40:19 | pixelma | if it was only one failed hunk to correct manually... :\ |
| 18:41:29 | gevaerts | pixelma: if you open the files that fail (the originals, not the patch), and change the "$Id:.....$" bits to "$Id$", the patch applies |
| 18:41:43 | | Quit FlynDice (Remote host closed the connection) |
| 18:42:42 | pixelma | well, it's the same as applying the things in the .rej |
| 18:46:05 | | Quit CGL (Remote host closed the connection) |
| 18:48:08 | | Quit Giova (Quit: Sto andando via) |
| 18:48:27 | pixelma | or not :( no. fun. |
| 18:51:34 | | Join m0ar [0] (~somalier@90-230-26-31-no23.tbcn.telia.com) |
| 18:52:39 | m0ar | My clip+ has been acting strange the last couple of days, instead of skipping to the next track when pressing >>| it just skips 0.001 sec forward in the song. I have tried to locate the setting, but had no luck. What might I have touched? |
| 18:53:48 | kugel | how did you measure the 0.001s? |
| 18:54:02 | m0ar | My mind os powerful. |
| 18:54:16 | m0ar | kugel: Just estimating, it's prolly like 0.2 or sumting |
| 18:54:41 | kugel | use real words please |
| 18:55:08 | m0ar | kugel: Oh well, If I keep it pressed down it searches the track forward as usuam |
| 18:55:33 | m0ar | kugel: but a swift click does not change the track, it just skips an extremely small bit forward |
| 18:55:36 | m0ar | Get it? |
| 18:55:58 | kugel | perhaps you have enabled "prevent track skipping" |
| 18:56:55 | wodz | pixelma: when I finish transparency handling I'll provide patch witch will apply cleanly to svn |
| 18:56:59 | m0ar | Ah damn, I even recall doing that when you mention it |
| 18:57:00 | m0ar | kugel: ^ |
| 18:57:19 | m0ar | kugel: Never really understood what that setting did, but i feel so retarded right now.. Thanks mate |
| 18:57:57 | kugel | it causes some confusion, you're not the first one |
| 18:58:56 | m0ar | kugel: Good ;) |
| 18:59:18 | m0ar | It's there to prevent accidental trackchanges for things like audiobooks i guess? |
| 19:00 |
| 19:00:41 | kugel | yws |
| 19:00:49 | kugel | yes* |
| 19:01:42 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 19:01:57 | m0ar | Just wondering, what is there to solve before the clip+ can be called stable? |
| 19:04:17 | gevaerts | Possibly USB, but also that it's not a good idea (as we noticed with the clip) to promote a target to stable when we're not doing a new release |
| 19:05:25 | m0ar | gevaerts: You mean filetransferring while connected via usb? What do you mean with the last thing? |
| 19:07:00 | gevaerts | m0ar: basically that declaring a target "stable" should be done at the same time that we release 3.7, or 3.8, or whatever. If it's done in between, various scripts and bits of the website get confused |
| 19:07:45 | gevaerts | There are now e.g. various links to a 3.6 build for the Clip, which doesn't exist, because the Clip wasn't stable yet when 3.6 was released |
| 19:08:36 | m0ar | Ah, thank you |
| 19:09:01 | gevaerts | So we either have to fix those, or just not declare targets stable at random times |
| 19:12:11 | | Join sasquatch [0] (~username@df01ppp031.eplus-online.de) |
| 19:15:31 | | Quit utanapischti (Ping timeout: 240 seconds) |
| 19:18:37 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 19:24:03 | | Quit anewuser () |
| 19:24:07 | | Quit mirak_ (Read error: Connection reset by peer) |
| 19:25:24 | | Join mirak_ [0] (~mirak@81-64-223-104.rev.numericable.fr) |
| 19:33:47 | | Join pamaury [0] (~quassel@dhcp-128-203.residence.ens-lyon.fr) |
| 19:33:47 | | Quit pamaury (Changing host) |
| 19:33:47 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 19:33:58 | | Quit jimbo () |
| 19:42:16 | | Quit mirak_ (Read error: Connection reset by peer) |
| 19:43:16 | | Join mirak_ [0] (~mirak@81-64-223-104.rev.numericable.fr) |
| 19:44:21 | | Quit Jerom (Read error: Connection reset by peer) |
| 19:44:34 | | Join Jerom [0] (~jerome@95.171.137.111) |
| 19:47:13 | | Join BoomerET [0] (pickme@c-98-224-26-185.hsd1.ca.comcast.net) |
| 19:47:43 | BoomerET | I have an iPod Nano 2nd Gen I'd like to install rockbox on... The installer said it was successful, but I still can't seem to use it... |
| 19:48:16 | BoomerET | I hold down the play button to turn it off, and the screen goes black, but if I press menu, it comes on immediatly, not at all like it's booting |
| 19:48:38 | BoomerET | I've never used a nano before, I'm used to my 5th Gen iPod |
| 19:48:57 | BoomerET | and yes, I have the manual open in front of me. |
| 19:51:34 | *** | Saving seen data "./dancer.seen" |
| 19:51:57 | | Join Jerom1 [0] (~jerome@95.171.137.111) |
| 19:51:57 | | Quit Jerom (Read error: Connection reset by peer) |
| 19:52:28 | BoomerET | Got it working, had to install the bootloader (even though it told me it was already installed) |
| 19:53:55 | TheSeven | even if the bootloader was installed before (but the apple firmware booted through it), the ipod won't reboot completely unless the firmware partition is touched again (by reinstalling the bootloader) |
| 19:54:12 | TheSeven | those things don't power off completely when holding play |
| 19:54:14 | BoomerET | Thanks! |
| 19:54:16 | | Join Evilnick_ [0] (~Evilnick@cpe-24-193-43-185.nyc.res.rr.com) |
| 19:54:19 | BoomerET | I see that now ;) |
| 19:54:34 | TheSeven | holding menu+select for 5 seconds will force it to reboot |
| 19:55:17 | BoomerET | I'm good to go, appreciate the help. |
| 19:55:29 | BoomerET | I can switch back and forth between both now. |
| 19:56:01 | | Quit Evilnick__ (Ping timeout: 276 seconds) |
| 20:00 |
| 20:07:19 | | Join Evilnick__ [0] (~Evilnick@cpe-24-193-43-185.nyc.res.rr.com) |
| 20:09:41 | | Quit MagusG (Ping timeout: 264 seconds) |
| 20:10:17 | | Quit Evilnick__ (Read error: Connection reset by peer) |
| 20:11:01 | | Quit Evilnick_ (Ping timeout: 245 seconds) |
| 20:17:02 | | Join stooo [0] (~sto@g226209196.adsl.alicedsl.de) |
| 20:17:16 | | Join evilnick [0] (~Evilnick@cpe-24-193-43-185.nyc.res.rr.com) |
| 20:17:56 | | Quit stooo (Remote host closed the connection) |
| 20:19:04 | | Join stooo [0] (~sto@g226209196.adsl.alicedsl.de) |
| 20:19:05 | | Quit stooo (Client Quit) |
| 20:21:26 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 20:29:52 | | Quit froggyman (Quit: Bye) |
| 20:30:13 | | Quit Staphylo (Quit: Bye les gens =)) |
| 20:36:40 | | Quit mirak_ (Read error: Connection reset by peer) |
| 20:37:37 | | Join mirak_ [0] (~mirak@81-64-223-104.rev.numericable.fr) |
| 20:38:13 | | Quit elcan (Read error: Connection reset by peer) |
| 20:38:58 | | Join elcan [0] (~loaa@pr0.us) |
| 20:40:24 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 20:40:51 | | Quit wodz (Quit: Leaving) |
| 20:42:42 | | Join Benjamin_ [0] (~Benjamin@5ac4fbc5.bb.sky.com) |
| 20:43:11 | | Quit elcan (Ping timeout: 240 seconds) |
| 20:43:12 | Benjamin_ | Could anyone explain to me why once i've installed rock box 3.6 on ipod nano 1g |
| 20:43:35 | Benjamin_ | why the /.rockbox/ folder doesnt show up? |
| 20:44:06 | | Join elcan [0] (user36@pr0.us) |
| 20:44:11 | gevaerts | In the rockbox file browser you mean? |
| 20:44:30 | gevaerts | You can change the "show files" setting to show hidden files too |
| 20:44:50 | gevaerts | Most people don't need to see .rockbox :) |
| 20:44:54 | Benjamin_ | im on a mac (new convert) so how do you do it:)? |
| 20:45:10 | Benjamin_ | haha i want to edit some stuff in it |
| 20:45:29 | gevaerts | Wait, you mean you don't see it on the mac? |
| 20:46:02 | Benjamin_ | yeah, ive got it mounted |
| 20:46:13 | Benjamin_ | but it only shows... |
| 20:46:17 | gevaerts | If so, you need to tell your mac to show hidden files, something with which anothe mac user might probably be able to help. |
| 20:46:24 | Benjamin_ | calendar contacts etc.. |
| 20:46:24 | * | gevaerts isn't a mac user |
| 20:46:50 | Benjamin_ | right ill have a look, google can be that user to help me haha |
| 20:47:28 | xnyhps | Benjamin_: You can press command-shift G when at the root of your device, and enter .rockbox to go there. |
| 20:48:01 | Benjamin_ | xnyhps thats fab |
| 20:48:05 | Benjamin_ | did the trick cheers guys:D |
| 20:52:51 | | Quit Benjamin_ (Quit: Benjamin_) |
| 20:52:56 | | Quit bmbl (Quit: Bye!) |
| 20:58:29 | | Quit GeekShadow (Quit: The cake is a lie !) |
| 21:00 |
| 21:02:09 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 21:05:31 | | Quit BoomerET () |
| 21:14:26 | | Join Evilnick_ [0] (~Evilnick@cpe-24-193-43-185.nyc.res.rr.com) |
| 21:17:12 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 21:17:51 | | Quit evilnick (Ping timeout: 240 seconds) |
| 21:19:45 | | Join TheSphinX^ [0] (~cold@p57A661B7.dip.t-dialin.net) |
| 21:23:44 | | Join plerohero [0] (~4d31f458@giant.haxx.se) |
| 21:23:48 | | Quit dys (Read error: Connection reset by peer) |
| 21:23:57 | plerohero | hello |
| 21:24:08 | plerohero | I have a simple question... |
| 21:24:44 | plerohero | when a dynamic playlist (not saved) reaches its end it's deleted? |
| 21:26:41 | plerohero | I usually play one track and then enqueue more tracks... but when the playlist reach its end its erased. |
| 21:26:48 | clone4crw | I think it's erased only when another one is created |
| 21:26:58 | plerohero | no |
| 21:27:17 | plerohero | its automatically deleted |
| 21:27:57 | plerohero | I use file browser to add a directory |
| 21:27:57 | clone4crw | And you want to be kept? |
| 21:28:01 | plerohero | yes |
| 21:28:16 | clone4crw | on the main menu playlists > save current playlist |
| 21:28:43 | plerohero | i dont want it to be physically saved |
| 21:29:27 | plerohero | i just want to have a persistant playlist lets say |
| 21:30:04 | plerohero | just like amarok or foobar playlist |
| 21:30:13 | plerohero | you add your songs to the playlist |
| 21:30:25 | plerohero | it plays them in the order you want |
| 21:30:42 | plerohero | if it ends its not destroyed |
| 21:31:11 | plerohero | nor you have to store it manuallly every time |
| 21:31:46 | clone4crw | oh i see what you mean. |
| 21:31:46 | gevaerts | It doesn't look deleted to me... |
| 21:32:00 | gevaerts | plerohero: when it reaches the end, there's still Playlists->Current Playlist |
| 21:32:59 | gevaerts | ok, that doesn't survive reboot |
| 21:33:32 | clone4crw | no, i think he's going to have to save it to disk. |
| 21:34:37 | clone4crw | So, I created a playlist of some random songs, and hit stop, and it persists in Current Playlist and can resume it |
| 21:35:05 | bertrik | this behaviour of rockbox confuses me a bit too |
| 21:35:44 | gevaerts | It's in a very vague way related to not saving pitch and timestretch settings |
| 21:36:11 | gevaerts | I'd like not using the player for half an hour be the same as shutting it down and booting it again in half an hour |
| 21:36:28 | clone4crw | And that playlist is still there after I reboot. huh. |
| 21:36:49 | gevaerts | clone4crw: yes, it's a playlist that *ended* that behaves differently |
| 21:37:17 | clone4crw | OH. I have mine set to repeat all. That's why. |
| 21:37:28 | gevaerts | Yes, it never ends then :) |
| 21:38:25 | plerohero | i thought it was deleted |
| 21:38:40 | clone4crw | OK, so I set repeat to off, and I still see the playlist in Current Playlist |
| 21:38:42 | plerohero | its in the Playlist->Current playlist |
| 21:39:08 | gevaerts | clone4crw: yes, until you reboot. (unless you just stopped it, which is different) |
| 21:39:42 | gevaerts | A playlist that didn't reach its end is *always* persisted |
| 21:40:24 | clone4crw | Yeah, I see now. Hmmm... Think it should be an option to always persist unless a new one is started? |
| 21:40:28 | | Join Horschti [0] (~Horscht@xbmc/user/horscht) |
| 21:40:43 | gevaerts | clone4crw: actually, I see no good reason to clear it |
| 21:40:59 | gevaerts | So I don't see the need for an option. I just think current behaviour is wrong :) |
| 21:41:11 | plerohero | thanks for clearing this up! bye (i think it should be documented in the manual somehow) |
| 21:41:42 | plerohero | if i want it stored ermanently i'll use repeat all |
| 21:42:30 | plerohero | i think the behaviour of amarok or foobar playlist would be better. |
| 21:43:07 | | Join [sko] [0] (~sko]@p57A99021.dip0.t-ipconnect.de) |
| 21:43:14 | * | gevaerts has no idea how those behave |
| 21:43:40 | clone4crw | I don't use either, but MediaMonkey always persists unless you start a new playlist |
| 21:43:54 | plerohero | that's their behaviour |
| 21:44:11 | | Quit Nausicaa (Ping timeout: 265 seconds) |
| 21:44:31 | gevaerts | What does "always persists" mean *exactly*? Is the only difference that we don't keep it after reboot? |
| 21:44:47 | | Quit Horscht (Ping timeout: 272 seconds) |
| 21:44:51 | clone4crw | Pretty much |
| 21:44:58 | plerohero | that's one point |
| 21:45:01 | plerohero | another on |
| 21:45:06 | plerohero | is that |
| 21:45:12 | plerohero | one is that |
| 21:45:22 | plerohero | if my playlists reaches the end |
| 21:45:22 | | Join slothearn [0] (~euclid@pool-98-111-116-30.hrbgpa.fios.verizon.net) |
| 21:45:28 | plerohero | and i click play |
| 21:45:31 | AlexP | please don't use the enter key as punctuation |
| 21:45:33 | * | TheSeven wonders if plerohero's keyboard has a spacebar |
| 21:46:25 | AlexP | gevaerts: I agree - I've never understood why the end of a playlist means it disappears |
| 21:46:42 | plerohero | if my playlists reaches the end and i click play it should not respond "nothing to resume" |
| 21:46:43 | gevaerts | AlexP: well, technically it doesn't. It just doesn't get saved :) |
| 21:47:06 | AlexP | gevaerts: Ignore what I say and just listen to what I mean ) |
| 21:47:08 | bertrik | plerohero, you mean you expected it to be stopped and rewound? |
| 21:47:13 | plerohero | I'm not a native english speaker so ignore my mistakes please.. |
| 21:47:23 | AlexP | *:) |
| 21:47:37 | AlexP | bertrik: It should restart IMO |
| 21:47:46 | * | gevaerts disagrees |
| 21:48:02 | AlexP | How do I play it again if I want to? |
| 21:48:20 | slothearn | it should stop at the last track if repeat isn't enabled. |
| 21:48:26 | slothearn | but replay the last track if play is pressed |
| 21:48:28 | plerohero | @alexp you go to playlists->view current playlist |
| 21:48:44 | AlexP | Seems a bit of a long way round |
| 21:48:51 | gevaerts | If I listen up to the end of a playlist, and then I fall asleep, and the next day I restart the player, and the start screen is set to WPS, should it restart the playlist? If so, why do need repeat modes? |
| 21:49:17 | AlexP | To restart automatically |
| 21:49:19 | plerohero | beacuase i'm lazy :-p |
| 21:49:38 | AlexP | (why there are repeat modes that is) |
| 21:49:38 | gevaerts | So people who *don't* want to listen to the same thing again aren't allowed to be lazy? |
| 21:49:43 | plerohero | because i'm lazy :-p |
| 21:49:59 | AlexP | gevaerts: How does it impact you if you don't want to listen again? |
| 21:50:26 | gevaerts | AlexP: I have to stop playback and leave the WPS first |
| 21:50:41 | AlexP | OK, I see that if you have it set to WPS on start |
| 21:50:52 | gevaerts | Which is about as many keypresses as you need to go to current playlist and start again :) |
| 21:51:05 | gevaerts | (provided it gets saved) |
| 21:51:21 | AlexP | I don't actually mind if play restarts it or not, it just seems that the method of restarting is a bit baroque |
| 21:51:32 | AlexP | And yes, the real issue is the not saving it |
| 21:51:35 | *** | Saving seen data "./dancer.seen" |
| 21:51:40 | slothearn | here's a question, why do I sometimes have to use multiple keypresses on an iPod 5G? |
| 21:51:55 | slothearn | doesn't always work the first time. I've noticed this :O |
| 21:52:31 | slothearn | it's also very intolerant of accidental presses. like the menu/select reset combo |
| 21:52:44 | slothearn | that sometimes needs to be like 2-3 times to get it to work. |
| 21:52:59 | slothearn | I'm assuming because my fingers slide ever so slightly and register as scrolls. |
| 21:53:08 | gevaerts | slothearn: I know there has been an issue with the first keypress after leaving a plugin, but I think that's fixed |
| 21:53:20 | gevaerts | Apart from that, I'm not aware of any issues |
| 21:53:29 | bertrik | gevaerts, no, it's not fixed, but we do know what causes it |
| 21:53:30 | slothearn | gevaerts: I thought it was just my iPod tbh, but it works fine in the official firmware |
| 21:54:01 | domonoky1 | slothearn: the reset combo isnt controlled by rockbox, its a hardware feature.. |
| 21:54:05 | AlexP | gevaerts: Would it be difficult to save the dynamic playlist? I'm assuming not very |
| 21:54:17 | slothearn | domonoky1: that's quite odd then :O |
| 21:54:19 | | Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) |
| 21:54:30 | gevaerts | AlexP: I'd estimate three days to understand the code, and then change one line :) |
| 21:54:43 | AlexP | heh :) |
| 21:55:06 | gevaerts | I mean, it *is* saved normally |
| 21:56:23 | AlexP | yeah, just not when finished |
| 21:57:03 | plerohero | @alexp it's saved but it is moved to playlists->current playlist |
| 21:57:37 | slothearn | Twitter in IRC :-D fun |
| 21:57:39 | gevaerts | plerohero: it's *not* saved. It's gone after reboot |
| 21:57:46 | plerohero | there are two behaviours hereoyt saving playlists after reboot and moving the current playlist when it reach its end |
| 21:57:47 | AlexP | plerohero: You don't need the @ |
| 21:58:28 | gevaerts | Either that or the restore sees the end of playlist and then forgets the lot |
| 21:58:34 | slothearn | "al[tab]" message |
| 21:58:52 | bertrik | argh, so possibly someone at some point added extra code for the current behaviour :) |
| 21:59:16 | gevaerts | bertrik: possibly :) |
| 21:59:28 | gevaerts | But I can't find out who it was unless I find where that code is :) |
| 21:59:40 | * | kugel also doesn't understand the people that prefer the most annoying splash & destroyed playlist over just restarting the playlist |
| 22:00 |
| 22:00:03 | AlexP | Well, I'm not too bothered about how to resume it, the main thing is saving a finished playlist over reboot |
| 22:00:08 | gevaerts | kugel: I *do* understand that! |
| 22:00:16 | gevaerts | Don't you dare change *that* part! |
| 22:00:44 | kugel | I'm fine with repeat all so don't worry :) |
| 22:00:51 | | Quit Evilnick_ (Ping timeout: 240 seconds) |
| 22:01:04 | * | gevaerts breathes again |
| 22:01:50 | kugel | but I still think it doesnt make sense |
| 22:02:40 | plerohero | whether behaviour changes or not I think it should be documented. I always thought that my current playlist was deleted.... |
| 22:03:09 | AlexP | plerohero: Patches are welcome to the manual |
| 22:09:37 | clone4crw | gevaerts: by the way, I saw your feedback. I'm working on some new BMPs right now, and the manual. If I'm lucky I'll have both done by tonight |
| 22:14:29 | | Quit plerohero (Quit: CGI:IRC) |
| 22:18:08 | gevaerts | clone4crw: great. I'll see that tomorrow then I guess |
| 22:18:22 | * | gevaerts finds the way the reload on boot is handled \☺/ |
| 22:25:06 | | Join crow [0] (~crowmo@chello080108001109.35.11.vie.surfer.at) |
| 22:25:28 | crow | Hi, Whats status of Ipod Nano 2g (4gb model)? i see on wiki post from 2009. |
| 22:28:12 | bertrik | Does loading a bookmark erase the current dynamic playlist? |
| 22:28:30 | TheSeven | crow: some minor issues left, but no blockers |
| 22:28:42 | gevaerts | bertrik: yes |
| 22:28:54 | TheSeven | ready for everyday use, concerning battery runtime it's slightly worse than the apple firmware |
| 22:30:18 | | Join Figa [0] (~filip_gla@69.38.broadband10.iol.cz) |
| 22:32:06 | Figa | Hi I have problem with convbdf I have problem with this utility. I know that I am in rockbox room. I hope that it does not matter. Is there any who could help me please? |
| 22:33:38 | gevaerts | AlexP: I have it working :) |
| 22:33:56 | AlexP | gevaerts: Ace :) |
| 22:34:08 | AlexP | Was it one line? :P |
| 22:34:23 | | Join krabador [0] (~krabador@host237-217-dynamic.117-80-r.retail.telecomitalia.it) |
| 22:34:47 | | Quit lestatar (Read error: Connection reset by peer) |
| 22:34:59 | gevaerts | Depends |
| 22:35:03 | crow | TheSeven so i can try 3.6 on it? first to flash bootloader? |
| 22:35:27 | gevaerts | To just get the "view current playlist" bit to work, it was half a line |
| 22:35:59 | gevaerts | To *also* get "save current playlist" to work, *without* doing "view current playlist" first, there's another line |
| 22:36:11 | gevaerts | I'm now seeing if I can now remove lines elsewhere :) |
| 22:36:41 | AlexP | haha :) |
| 22:37:29 | gevaerts | hm, maybe better not |
| 22:37:38 | | Quit TheSeven (Ping timeout: 252 seconds) |
| 22:38:25 | pixelma | hur... flyspray notification mails seem to start working for me again. At least I got one now, hopefully it stays that way |
| 22:39:18 | pixelma | working I mean, not keep "staying" at one mail ;) |
| 22:42:27 | | Quit BHSPitMonkey (Read error: Operation timed out) |
| 22:42:58 | | Join lestatar [0] (~chatzilla@cpe-72-229-41-214.nyc.res.rr.com) |
| 22:43:50 | gevaerts | AlexP: FS #11644 |
| 22:44:29 | | Join nihilanth [0] (~zach@72-161-51-220.dyn.centurytel.net) |
| 22:45:46 | AlexP | gevaerts: Coolio! I don't imagine it really needs testing? |
| 22:46:11 | gevaerts | AlexP: mainly review by people who understand this code I think |
| 22:46:21 | AlexP | yeah, that's what I thought :) |
| 22:47:20 | | Part Figa |
| 22:53:43 | crow | i just finished flashing bootloader and rockbox.. but how to restart ipod nano 2g? |
| 22:55:04 | crow | ah got it nice rock box is here :) |
| 22:56:27 | | Quit Jaykay (Ping timeout: 252 seconds) |
| 22:58:32 | pixelma | how likely is something overflowing being the cause of the screen corruption problem and could an "stkov main" when doing something in the WPS be related? |
| 22:59:02 | gevaerts | something overflowing could basically cause anything |
| 22:59:16 | pixelma | the latter happens on my M5 now from time to time while skipping tracks, leaving or entering the WPS, asjusting volume or such |
| 22:59:58 | pixelma | is there something I could test to help debugging this? |
| 23:00 |
| 23:00:45 | | Quit nihilanth (Read error: Connection reset by peer) |
| 23:01:55 | gevaerts | probably. Now just to think what... :) |
| 23:04:11 | gevaerts | pixelma: the easiest first test would probably to try a larger stack |
| 23:04:21 | pixelma | maybe "catch mem accesses" can give me some addresses but that's not guaranteed |
| 23:05:14 | pixelma | gevaerts: where and how? :) |
| 23:07:30 | gevaerts | pixelma: for ondio, firmware/target/sh/archos/app.lds. Change the 0x2000 to 0x4000 |
| 23:07:45 | gevaerts | For m5 unfortunately IRAM seems to be nearly full, so it's not that easy |
| 23:08:26 | pixelma | the "stkov main" is on my M5 |
| 23:08:46 | gevaerts | yes, I know |
| 23:08:49 | | Join Heis [0] (~krdahl@ip-62-143-83-30.unitymediagroup.de) |
| 23:09:02 | pixelma | on the Ondio I still have trouble with "my" WPS though |
| 23:10:30 | gevaerts | Another thing you could try is adding -DBUFFER_ALLOC_DEBUG to EXTRA_DEFINES in the makefile, to see if something overflows a buffer_alloc()ed buffer |
| 23:10:33 | | Join nihilanth [0] (~zach@tuxhacker/Nihilanth) |
| 23:10:43 | gevaerts | (with a recent checkout. I only added that today...) |
| 23:10:55 | | Quit krabador (Ping timeout: 272 seconds) |
| 23:10:59 | | Part Heis |
| 23:11:51 | nihilanth | My ipod 5g is stuck in the rockbox bootloader with a checksum error, I already tried hard resetting and disk mode but neither seem to work |
| 23:11:58 | nihilanth | is there anything else i should try? or should i just wait until the battery dies |
| 23:13:01 | AlexP | reset is a hardware thing, just keep trying |
| 23:13:27 | CIA-81 | New commit by bertrik (r28176): Warn about erasing dynamic playlist when loading bookmark - FS #10482 by Tuomas Airaksinen |
| 23:14:22 | nihilanth | it's only supposed to take ~5 seconds right? should I try buttons again every so often or just keep them held down? |
| 23:14:48 | gevaerts | nihilanth: did you switch hold on and off? Sometimes that makes a difference |
| 23:15:11 | nihilanth | gevaerts, yeah I've done that a few times |
| 23:15:18 | CIA-81 | r28176 build result: All green |
| 23:15:22 | nihilanth | it's being real stubborn |
| 23:15:39 | Torne | hold it for 30 seconds or more |
| 23:15:42 | Torne | seriously |
| 23:16:17 | pixelma | gevaerts: ok, I'll try the first on my Ondio and the latter on the M5 |
| 23:16:34 | nihilanth | alright, i'll keep at it. thanks for the encouragement :P |
| 23:16:37 | Torne | it resets eventually, if you hold it long enough, every case we've heard of :) |
| 23:16:57 | gevaerts | pixelma: http://pastebin.com/2KCgscpf should give you a much bigger main stack on m5, at the cost of less IRAM for plugins/codecs (so there may be some performance problems with some codecs). I'd use that for a while, and check the stack usage in the debug menu every now and then |
| 23:17:17 | gevaerts | The big thing will be to find out what's using all this stack though |
| 23:18:08 | | Quit TheSphinX^ (Quit: XChat) |
| 23:19:56 | | Quit feisar- (Ping timeout: 276 seconds) |
| 23:20:14 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 23:21:53 | | Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 23:24:02 | pixelma | I remember checking the stack usage when investigating the nested conditionals problem with Lear and he made me check the numbers on the Ondio and it didn't seem too much |
| 23:24:49 | | Quit crow (Remote host closed the connection) |
| 23:24:56 | gevaerts | right |
| 23:25:03 | gevaerts | It's too much onm5 though |
| 23:25:41 | * | gevaerts would like to see 3.7, but this sort of issue really is a release blocker... |
| 23:26:01 | | Quit ender` (Quit: The latest survey shows that 3 out of 4 people make up 75% of the world's population.) |
| 23:27:09 | pixelma | indeed |
| 23:27:26 | | Quit [sko] (Read error: Connection reset by peer) |
| 23:27:31 | | Join [AndrewR] [0] (~andrewrot@d24-36-251-35.home1.cgocable.net) |
| 23:27:57 | [AndrewR] | hello, I'm trying to write a plugin, and I have rockboxui compiling.. I added my plugin to SOURCES and CATEGORIES, but it's not showing up in the menu |
| 23:28:52 | [AndrewR] | anything else I need to do? |
| 23:29:36 | gevaerts | You're trying this with a simulator build? |
| 23:29:42 | gevaerts | Did you run make install? |
| 23:30:09 | [AndrewR] | um at some point I think I told it to build simulator, yeah |
| 23:30:22 | [AndrewR] | if I rm rockboxui it rebuilds it with make |
| 23:30:53 | [AndrewR] | the simulator runs, my plugin's just not in the apps list |
| 23:31:16 | gevaerts | Does your plugin get built? |
| 23:31:25 | [AndrewR] | it does, I see it compiling |
| 23:31:28 | [AndrewR] | to a .rock file |
| 23:31:28 | pixelma | gevaerts: I should really try an unaltered build from after yesterday's fixes first though, I guess - just remembered that I didn't update the M5 today... |
| 23:31:45 | [AndrewR] | I can try make install.. |
| 23:31:47 | gevaerts | pixelma: ah, yes. Might be useful :) |
| 23:32:02 | pixelma | just the other two |
| 23:32:27 | gevaerts | [AndrewR]: the sim doesn't get any plugins if you don't do make install |
| 23:32:41 | [AndrewR] | ah, it shows up now, thanks! |
| 23:33:07 | | Join feisar- [0] (jljhook@irkki.fi) |
| 23:33:12 | [AndrewR] | so I should be doing make install each time? |
| 23:33:17 | gevaerts | yes |
| 23:33:25 | gevaerts | Or copy it by hand |
| 23:34:44 | [AndrewR] | ah, ok. thanks |
| 23:37:32 | | Quit pamaury (Remote host closed the connection) |
| 23:40:45 | pixelma | gevaerts: I could still run with the debug option, you mentioned, for a while. What will I see if it catches some error? |
| 23:40:56 | gevaerts | a panic |
| 23:41:08 | * | gevaerts looks up the actual text |
| 23:41:08 | pixelma | aha |
| 23:41:28 | | Part domonoky1 |
| 23:41:53 | gevaerts | "%s corrupted buffer %x start" or "%s corrupted %x end", with %s being the thread name, and %d being the address of the buffer |
| 23:42:17 | pixelma | I'll try that then |
| 23:42:46 | | Join Loto [0] (~ctrlproxy@xbmc/user/Loto) |
| 23:42:50 | | Part Loto |
| 23:42:51 | | Join Loto [0] (~ctrlproxy@xbmc/user/Loto) |
| 23:43:01 | gevaerts | That one might also slow down things a bit :) |
| 23:43:15 | gevaerts | Nothing like debugging options to improve performance |
| 23:48:13 | | Quit m0ar (Quit: leaving) |
| 23:51:36 | *** | Saving seen data "./dancer.seen" |
| 23:55:20 | | Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) |
| 23:57:49 | | Quit kugel (Remote host closed the connection) |
icon identifies that the person is a core developer (has commit access).