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

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

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

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2017-01-27

00:00:43 Quit petur (Quit: Leaving)
00:14:04 Quit Bilgus_ (Ping timeout: 240 seconds)
00:14:48 Join MrZeus1 [0] (~MrZeus@5ec21d62.skybroadband.com)
00:16:14 Quit MrZeus (Ping timeout: 255 seconds)
00:32:05 Quit ZincAlloy (Quit: Leaving.)
00:46:10 Quit girafe (Quit: Leaving)
00:46:48 Quit mutnai (Ping timeout: 260 seconds)
00:47:05***Saving seen data "./dancer.seen"
00:55:43 Quit shdwprince (Quit: My Mac has gone to sleep. ZZZzzz…)
01:00
01:03:09 Quit ender` (Quit: If someone's political stance requires preventing scientists from informing you about your own planet, that's not politics, it's oppression.— Katie Mack)
01:04:47pamaurydamn, the Qt folks have some interested twist
01:05:36pamaurythey came up with qstyleoptionviewitem, then qstyleoptionviewitemv2, v3, v4, each one inheriting the previous, which means you need v4 to get all the fields
01:05:56pamaurythen in 5.7, the decide that qstyleoptionviewitem should have all the fields from v4 and stop this version mess
01:06:00pamauryand deprecate qstyleoptionviewitemv4
01:06:30pamaurywhich means the only reliable way of using styled delegate is to use qstyleoptionviewitemv4 if you want to work on Qt4 and 5, but it's also deprecated
01:06:42pamaurythat's stupid
01:06:47 Join alexweissman [0] (~alexweiss@149-160-168-106.dhcp-bl.indiana.edu)
01:12:00 Quit alexweissman (Ping timeout: 276 seconds)
01:20:58 Join Bilgus [0] (~Bilgus@gateway/tor-sasl/bilgus)
01:51:05 Quit Senji_ (Ping timeout: 256 seconds)
01:53:37 Quit pamaury (Ping timeout: 260 seconds)
01:56:21chrisjjpamaury, Thanks. Which difference http://i.imgur.com/nGqKGVg.png is the RAM size?
02:00
02:01:00dunxqstyleoptionviewitem is quite a mouthful
02:03:02[Saint]do u evn qstyleoption, bruh?
02:03:30 Quit xorly (Ping timeout: 252 seconds)
02:05:09 Quit __builtin (Ping timeout: 252 seconds)
02:06:30 Join __builtin [0] (~xray@rockbox/developer/builtin)
02:34:03chrisjj__builtin, good guess. Number of Creative players owned is 38.
02:38:34[Saint]We had two running theories.
02:39:20[Saint]That you either cycled back around from A~Z to A*, or that you named them after arbitrary objects. Like Nuts, or Cheese, or Air Conditioner.
02:42:14 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon)
02:45:01 Quit JdGordon (Ping timeout: 240 seconds)
02:47:07***Saving seen data "./dancer.seen"
03:00
03:00:46__builtinchrisjj: it was far from a guess ;)
03:03:00[Saint]Phases of the moon and a fair dice roll was also something I considered.
03:03:22[Saint]Or plucks from a bag of Scrabble tiles.
03:05:29 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net)
03:25:52 Part robertd1
03:27:14 Quit WakiMiko (Max SendQ exceeded)
03:27:52 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
04:00
04:06:12 Quit MrZeus1 (Ping timeout: 255 seconds)
04:15:06 Quit bluebrother (Disconnected by services)
04:15:11 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
04:17:43 Quit fs-bluebot (Ping timeout: 260 seconds)
04:31:17 Join fs-bluebot [0] (~fs-bluebo@xd9baf127.dyn.telefonica.de)
04:47:08***Saving seen data "./dancer.seen"
04:57:32 Quit naleo (Ping timeout: 256 seconds)
05:00
05:02:54 Quit Bilgus (Ping timeout: 240 seconds)
05:03:12 Quit [Saint] (Remote host closed the connection)
05:04:50 Join [Saint] [0] (~sinner@rockbox/staff/saint)
05:09:33fs-bluebotBuild Server message: 3New build round started. Revision 58b849c, 255 builds, 15 clients.
05:17:58 Join chrisb [0] (~chrisb@pool-71-175-249-93.phlapa.east.verizon.net)
05:21:38fs-bluebotBuild Server message: 3Build round completed after 725 seconds.
05:21:39fs-bluebotBuild Server message: 3Revision 58b849c result: All green
05:22:13dyspamaury: I have the SPI testpoints figured out, but not yet found an accessible reset pin to tristate the blackfin SPI port
05:22:44dyspamaury: Did you happen to spot a reset controller or a supervisor IC by chance?
05:23:23 Join naleo [0] (~naleo@unaffiliated/naleo)
05:30:12dys(closing the reset pinhole button powers the unit off… not very helpful)
05:37:25 Join Bilgus [0] (~Bilgus@gateway/tor-sasl/bilgus)
05:53:04Bilgus[Saint], anyone else interested G#1541 is up
05:53:05fs-bluebot3Gerrit review #1541 at http://gerrit.rockbox.org/r/1541 : 3Advanced Auto-Ranging Time Formatting For Menus (hh:mm:ss:mss) by William Wilgus
06:00
06:11:29 Quit TheSeven (Ping timeout: 245 seconds)
06:12:06 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
06:34:41 Quit amazoniantoad (Ping timeout: 255 seconds)
06:43:39 Quit advcomp2019_ (Ping timeout: 240 seconds)
06:47:11***Saving seen data "./dancer.seen"
06:49:24 Join amazoniantoad [0] (~golden@2603:3018:600:a000:fc94:8938:f194:b983)
07:00
07:05:44 Quit amazoniantoad (Ping timeout: 255 seconds)
07:18:06 Join amazoniantoad [0] (~golden@2603:3018:600:a000:fc94:8938:f194:b983)
07:27:41 Quit naleo (Quit: Leaving)
07:37:04 Quit chrisb (Ping timeout: 240 seconds)
07:51:09 Quit jhMikeS (Ping timeout: 240 seconds)
07:56:44 Quit [Saint] (Quit: Going down for scheduled maintenance)
08:00
08:03:22 Join [Saint] [0] (~sinner@rockbox/staff/saint)
08:07:33 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
08:23:14 Join ender` [0] (krneki@foo.eternallybored.org)
08:33:03 Quit [Saint] (Read error: Connection reset by peer)
08:34:29 Join [Saint] [0] (~sinner@rockbox/staff/saint)
08:35:17 Quit furrywolf (Ping timeout: 255 seconds)
08:43:51 Quit [Saint] (Quit: Quit)
08:44:30 Join athidhep [0] (~afoakf@unaffiliated/athidhep)
08:45:49 Quit pixelma (Quit: .)
08:45:49 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
08:46:00 Join amiconn [0] (~amiconn@rockbox/developer/amiconn)
08:46:00 Join pixelma [0] (~pixelma@rockbox/staff/pixelma)
08:46:44 Join [Saint] [0] (~sinner@rockbox/staff/saint)
08:47:12***Saving seen data "./dancer.seen"
08:51:25 Join petur [0] (~petur@rockbox/developer/petur)
08:56:28 Quit [Saint] (Read error: Connection reset by peer)
08:58:47 Join [Saint] [0] (~sinner@rockbox/staff/saint)
09:00
09:00:17 Quit [Saint] (Client Quit)
09:01:17 Join [Saint] [0] (~sinner@rockbox/staff/saint)
09:14:09 Quit The_Prospector (Read error: Connection reset by peer)
09:14:35 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman)
09:53:22 Quit elensil (Ping timeout: 240 seconds)
10:00
10:09:13 Join elensil [0] (~edhelas@2001:1c02:1903:d800:887c:5774:10b:f748)
10:28:48 Quit petur (Remote host closed the connection)
10:47:16***Saving seen data "./dancer.seen"
11:00
11:07:30 Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz)
11:22:08 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
11:59:09pamauryBilgus: do you think you could have a look at https://www.rockbox.org/tracker/task/10363#comment43861 ?
11:59:29pamauryit's a bug with chessbox and you have worked a lot on plugins now ;)
12:00
12:06:38pamaurychrisjj: re difference: the RAM size is not written anywhere. It involves putting 4 fields together in an equation.
12:06:38pamauryIn this case, register HW_DRAM_CTL11 (0x800E002C) has a field COLUMN_SIZE (10:8) which is 2 in one and 3 in the other.
12:23:44 Join shdwprince [0] (~textual@130.180.218.8)
12:25:01dyspamaury: Pulling the unidentified testpoints low via 1kΩ also didn't result in a reset :-/
12:25:18dysall that's missing from reading the spi flash is telling the blackfin to let go of the lines
12:25:22 Part shdwprince
12:37:29pamaurydys: can you sniff the wires when the SoC is starting ?
12:37:53pamauryie reset the whole thing, the soc starts reading, just capture all the transfers on the wire and with a bit of decoding you have the content of the flash
12:38:39pamauryI had this problem once and that the only solution I came up with when even pulling the pins doesn't work.
12:39:13dysI did watch the action on my scope on startup. No ready-to-use logic analyzer. I could use a fpga board to do the capturing, though that is a bit of an effort…
12:40:17dysi might try forcing the pins. the blackfin lines go through series-termination resistors. maybe they are large enough to foce the lines without doing damage
12:40:24pamauryah that's a shame. If the speed of that thing is not too high, maybe a micro-controller could capture the traffic ? (assuming you have some place where to store the data)
12:41:08dysit seems to load the 32 Mbit in about two seconds, so probably to fast for a µC
12:47:19***Saving seen data "./dancer.seen"
12:47:27pamauryyeah unless you have a 100Mhz+ uc it doesn't look easy to sniff it
12:47:32pamauryor fpga
12:48:14dysalso, if the blackfin switches the spi to multi-pin data out it adds another problem
12:48:14pamauryif your fpga has enough ram though, it could be "just" a matter of recronstructing the image in RAM and then download it to your PC.
12:48:29pamaurymulti-pin data ? what is that ?
12:49:07dysthe spi used supports parallel output on four lines IO1…IO4 in the pinout
12:49:41dysthe chips on x86 mainboard are routinely used in this mode
12:49:44dysit's a pita to sniff, i can tell
12:51:01dyslunch break over, need to cycle to work now… afk for another 6 hours
12:51:26pamauryah, I though spi was one wire of data onl
13:00
13:00:17 Join petur [0] (~petur@rockbox/developer/petur)
13:06:09chrisjjpamaury, Thanks. I see that HW_DRAM_CTL11 is read-write. Is this value that's found differing being written by software?
13:14:51 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:464:820c:5fb:4ae2)
13:20:22pamauryyes it is written by the RAM init code that runs really early at boot
13:21:29pamaurybut RAM isn't likely to explain the problem, the device has more RAM than expected, that simply means Rockbox uses only half of the RAM available
13:26:29chrisjjIs it theoretically possible to run code inside Rockbox that can detect the amount of RAM available?
13:28:04 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
13:28:14wodzchrisjj: sure, we do that on ipodvideo
13:28:39pamaurywodz: doesn't rockbox assume compile timed defined RAM amount ?
13:28:44pamaury*compile time
13:29:20wodzpamaury: ask gevaerts about details but a few years ago 32 and 64MB build of ipodvideo were merged into one
13:29:58pamauryah, I remember we indeed had two builds. I will look at the code
13:30:06pamauryalthough 32MB is already plenty
13:30:39wodzI wouldn't worry about 32MB considering that devices freeze randomly :-)
13:32:08chrisjjPlenty means only that there's no /good/ reason for Rockbox to detect the amount of available RAM :)
13:32:14chrisjjwodz: What devices freeze randomly?
13:32:24wodzchrisjj: yours?
13:32:27chrisjjNo.
13:33:06chrisjjOn the current build, they often BSoPO after about 22h.
13:33:33pamauryeven with voltage fix ?
13:33:33pamauryI think he was referring to your unit N
13:33:46 Quit Moarc (Ping timeout: 252 seconds)
13:34:15 Join Moarc [0] (~chujko@a105.net128.okay.pl)
13:34:40wodzchrisjj: Whatever, your units tend to have some problems and using just half of ram is the smallest
13:34:55chrisjjYes. On the current build (8fec364f6-170125 voltage fix g1533), they often BSoPO after about 22h.
13:34:56fs-bluebot3Gerrit review #1533 at http://gerrit.rockbox.org/r/1533 : 3zen/zenxfi: adjust maximum emi voltage by Amaury Pouly
13:35:39pamauryI thought you said they were working
13:35:55pamauryisn't 22h like empty battery anyway ?
13:36:12chrisjjpamaury, I think he wasn't referring to my Unit N, but even if he was, most Unit N fails are data aborts.
13:36:17pamaurydevices tend to power off after they run out of juice
13:36:50chrisjjpamaury, I said there were working while they were working. That was for the first few hours.
13:37:54chrisjj22h would be battery empty except all these unisa re on mains power. After finding high incidence of BSoPO when /charging/ from low battery, I am avoiding internal power for tests, for now.
13:38:03pamaurywodz: indeed core_allocator_init() has a hack to reduce audiobufend depending on probed memory
13:39:02 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51)
13:39:47pamauryif they only crash after 20h, that's an improvement
13:42:02pamauryI'll send you another build with any kind of frequency and voltage scaling disabled to see what happens
13:48:59pamaurychrisjj: https://www.dropbox.com/s/atgauqu26zpyf8s/firmware_zen_nodfs.nk?dl=0 (bootloader)
13:49:00pamauryand https://www.dropbox.com/s/ldac8l6ci8jpk33/rockbox_zen_nodfs.zip?dl=0
13:49:00gevaertspamaury, wodz: I suspect you can't use the exact same mechanism as the ipod video. That one (ab)uses the fact that on the 32MB one the RAM is mapped twice, so you can use the codec and plugin buffers at the end of the 64MB block on both, and you merely have to adjust the end of the audio buffer
13:49:19gevaertsIf the hardware does not map that RAM twice in that way, different approaches will be needed
13:53:06pamaurychrisjj: if you test those builds, can you, after you install both bootloader and rockbox, go to System > Debug > Show HW Info > clock and pastebin what you read ?
13:53:13pamaurygevaerts: I see
13:53:17pamaurylooks like a hack anyway
13:53:57pamauryon imx233 I'm mapping the lcd buffer at the end of ram currently so it wouldn't work
13:56:54 Quit wodz (Ping timeout: 255 seconds)
13:58:06pamaurychrisjj: re debug screen: I only care about the frequency on each clock (ie for each line the first word (the name) and the last number (the freq))
13:59:05gevaertsOh, it's a massive hack
13:59:29gevaertsBut it achieved the goal in less than ten lines of code
14:00
14:01:15 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
14:01:37 Quit wodz (Client Quit)
14:01:41pamaurydoes it really need to be a hack though ? fundamentally only the linker script ough to care about the exact memory size. And these days the audio buf is managed dynamically. Thus it should be possible to have a clean and generic solution where we map the audio buf at the end of ram and we can change it's size very early at boot before anyone uses it
14:01:56 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
14:06:01 Quit mutnai (Quit: Page closed)
14:13:23 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51)
14:18:39 Quit dfkt (Ping timeout: 240 seconds)
14:20:56 Join The_Prospector|2 [0] (~The_Prosp@c-73-239-179-79.hsd1.wa.comcast.net)
14:21:39 Quit wodz (Ping timeout: 240 seconds)
14:23:59 Quit The_Prospector (Ping timeout: 245 seconds)
14:24:24 Join dfkt [0] (~dfkt@unaffiliated/dfkt)
14:25:04 Join paulk-collins [0] (~paulk@gagarine.paulk.fr)
14:26:20 Quit dfkt (Client Quit)
14:28:23chrisjjpamaury, Actual minimum run time is 26h12m according to battery_bench and 25h44m according to Running Time. Agreed, an improvement over the ~3h previously - but this could be due only to my switch from internal to external power.
14:34:21chrisjjpamaury, I guess the nodfs build is expected to reduce the incidence of BSoPO. So I shall first text the voltage_fix on internal power to possibly get a high incidence of BSoPO.
14:35:12BilgusDoes it always last exactly that long (like +- 5%?)
14:35:44Bilguswhen it crashes that is
14:46:07 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com)
14:47:20***Saving seen data "./dancer.seen"
14:53:03chrisjjBilgus, I don't know if it crashes. The BSoPO may or may not be due to a crash.
14:53:11chrisjjTimes are:
14:53:16chrisjjUnit P: After 32h 30m, running
14:53:22chrisjjUnit L: After battery_bench 26h12m and Running Time 25h44m, BSoPO
14:53:28chrisjjUnit G: After battery_bench 28h06m and Running Time 27h25m, BSoPO
14:53:34chrisjjUnit Q: After battery_bench 28h43 Running Time 26h03m, Creative charging screen (black except for battery icon in top right)
14:55:41chrisjjFTR, that's for build 8fec364f6-170125 (voltage fix) on charger-powered Creative ZENs. Which RAM variant these are is unknown.
14:58:16Bilgushuh so battery bench is still running after this black screen or how are you calculating runtime?
15:00
15:00:52chrisjjZEN testers' Pro Tip: Running Time Total time is /not/ /necessarily/ /cleared/ when you use Windows Beyond Compare to delete .rockbox from the device and copy to the device a .rockbox from a distribution .ZIP (e.g. rockbox_zen_g1533.zip), then unplug, reset, and power-on.
15:00:54fs-bluebot3Gerrit review #1533 at http://gerrit.rockbox.org/r/1533 : 3zen/zenxfi: adjust maximum emi voltage by Amaury Pouly
15:02:02chrisjjBilgus, this Black Screen of Power Off does look 100% like a power off, so I can't see how BB can still be running. Running Time is not calculated by me, but read from System > Running Time.
15:04:25pixelmawhat should a black screen of power-off be? I mean if the device powers off the screen goes dark
15:05:04chrisjjCan you suggest other cause for the difference between battery_bench's last entry and Running Time?
15:05:53pixelmamaybe one thing doesn't get kept/written as often
15:07:33Bilgusah probabl what is happening is the last disk flush for run time never gets applied but its like 20 mins i'd think it'd flush in that amount of time
15:08:39chrisjjGreatest discrepancy is 2h40m.
15:09:41Bilguschriss it sounds annoying but have you tried playing a bunchj of tracks and recording the output on the PC to see if it stops at the same time as battery bench?
15:09:58chrisjjI haven't.
15:10:44Bilgusthat would pretty well answer the question without having to babysit the damn thing
15:10:51chrisjjbattery_bench writes every minute. Won't this will spin up the 'disc', and so get Running Time flushed to disc?
15:11:11Bilgusyou'd think?
15:11:17chrisjj:-)
15:11:38gevaertsFor starters, battery_bench does *not* write every minute
15:11:47gevaertsThat would make it entirely useless
15:12:05chrisjjSo how often does it write?
15:13:29Bilgusconversely If bench were running don't you think that running time would keep incrementing
15:13:29chrisjj(And if true, would someone please correct "# This plugin will log your battery performance in a # file (//battery_bench.txt) every minute.")
15:13:41gevaertsWhen the "disk" "spins up" (quotes to account for flash being a bit different) for other reasons, when the buffer is full, and on shutdown
15:13:51pixelmaI believe on disk access (which happen during rebuffer anyway)
15:14:28gevaertsIt records data every minute. Writing that to disk every minute would distort the results enough to make them worthless
15:14:33pixelmarebuffering for playback I mean
15:14:49chrisjjgevaerts, Wow. That's really disappointing. Thanks for the info.
15:15:10gevaertsYes, it's very disappointing that it works in a sensible way. We should fix that
15:22:36chrisjjpamaury, note the above re relying on battery_bench to record the runtime up to a BSoPO or crash.
15:23:26chrisjjBilgus, you'd think! :-)
15:26:40chrisjjI don't doubt Running Time is still incrementing a RAM variable (I can see this displayed value incrementing), but how often the persistent version is updated, I don't know.
15:28:43 Quit jhMikeS (Ping timeout: 276 seconds)
15:29:08gevaertsAt least in the storage spinup callback
15:31:04gevaertsWhich storage driver are you looking ar?
15:36:24gevaertsHmmm
15:38:02gevaertspamaury: am I right in thinking that (many?) sd drivers call call_storage_idle_notifys() on SYS_TIMEOUT (instead of spindown which is of course not possible), which is triggered by the backlight turning off?
15:41:36gevaertsAt first sight it looks to me as if on targets where we don't use rtc nvram (which is most of them), "nvram" is only written to disk from a storage idle callback, and on settings save
15:41:57gevaertsIf the storage idle callbacks aren't called near shutdown, that could cause what chrisjj is seeing
15:58:34chrisjjgevaerts, I don't know which storage drive in used in this port, being for ZEN. No save near shutdown would also explain loss of UI changes to Run Time that I've reported.
15:58:37chrisjjHow frequent is this storage idle callback?
16:00
16:06:22 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com)
16:14:49 Join JanC_ [0] (~janc@lugwv/member/JanC)
16:14:58 Quit JanC (Remote host closed the connection)
16:16:04 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC)
16:26:55 Quit alexweissman (Remote host closed the connection)
16:35:23 Join Bilgus_ph [0] (~Bilgus_ph@108.115.82.231)
16:36:45Bilgus_phPAMAURY: ill have a look at chessbox in a day or two
16:36:55 Quit Bilgus_ph (Remote host closed the connection)
16:46:39pamaurygevaerts: I'll check but yes I think storage idle is called after some storage operation was done and X seconds later no activity was recorded.
16:47:14pamauryI don't know how "nvram" is handled on player where it does not exists, I would expect the code to flush it to disk on shutdown
16:47:23***Saving seen data "./dancer.seen"
16:48:43pamaurychrisjj: if you let the player plugged for 22h, can you check if the battery isn't low ? Because on imx233, there is smart trick (TM) to make sure battery doesn't discharge after charge timeout
16:48:51pamauryand maybe this trick doesn't work on stmp3700
16:48:59pamaurywhich means your battery charges and then discharges
16:49:05pamauryand then the device powers down
16:50:29pamauryactually I am 98.31478% sure it's not working on smtp3700 and battery is discharging after charging times out
16:56:27*pamaury starts his ZEN X-Fi to check
16:57:09gevaertspamaury: I'd expect it to be called on shutdown as well, but I didn't find that
16:58:06pamaurywhy ? it doesn't really make sense
16:58:16 Join furrywolf [0] (~randyg@107.25.30.188)
16:59:09pamauryI mean it's a hack, I would expect the shutdown to nvram_flush() or something
16:59:28*pamaury looks at the code
17:00
17:00:40gevaertsI might be wrong of course. Callback hooks are easy to miss
17:07:36pamauryI think you are right, it looks like the nvram code only writes to file on idle callback
17:08:36 Join Senji [0] (~Senji@85.187.103.250)
17:08:47pamaurythe code in settings.c is a bit confusing
17:09:32pamaurydamn, why people don't comment public API x-(
17:09:54pamaurywhat is status_save() and settings_save();
17:11:01pamaurygevaerts: do we actually store ALL settings to NVRAM on some targets ?
17:12:16gevaertsNo, definitely not
17:12:36gevaertsIIRC nvram is 44 bytes on those systems that actually have it for real
17:12:39pamauryalso seriously rtc_read(0x14+i), it really looks like HAVE_RTC_RAM == I_HAVE_FUCKING_ARCHOS
17:12:55gevaertsYes :)
17:13:36chrisjjpamaury, re storage commits, I'd be interested to know that value of that X.
17:14:02pamauryit doesn't matter, it's a few seconds
17:15:29pamaurygevaerts: when is SYS_TIMEOUT sent ?
17:15:46gevaertsAccording to my grepping when the backlight goes off
17:16:32chrisjjpamaury, re battery, I have one (P) that I believe* to have been running for 36h.
17:16:42chrisjj* I now have no reliable way I know to find the runtime of a device from the device itself
17:19:59pamaurygevaerts: I think all sd drivers use the same copy pasted code (one of the many reasons I think we need a generic sd/mmc driver). That SYS_TIMEOUT stuff looks shaky
17:20:12chrisjjAh, scratch that 'believe'. I just tried to check WPS, but that main menu command is 'Resume playback' and gives "Error accessing playlist control file". And the status bar shows the Stopped icon (solid square). So I assume playback actually stopped for some reason in the last 36h, even though there is no BSoPO.
17:20:50gevaertspamaury: I'm assuming it was something that's done every now and then, but not too often...
17:20:55chrisjjThis means the only run that survived past 29hrs was a faulty test.
17:21:24pamaurychrisjj: did you see my comment/question on battery ?
17:21:45chrisjjYes. My [16:16] is the answer.
17:23:33chrisjjAnswering your question, yes the player was plugged for 22h (though not playing for all that) and the best measure of whether battery is low is from the uncalibrated RB meter, which says 50%.
17:24:38pamauryit's not really an answer, a reliable way is to go to System > Debug > Show battery info and check battery voltage
17:24:45*pamaury will commit battery calibration
17:25:15pamaurygevaerts: probably SYS_TIMEOUT is not very well named or deserves a comment
17:25:57pamauryI fail to see why so many things are related to backlight timeout, it doesn't make sens
17:26:37gevaertsI agree, but I suspect it probably never meant to be used outside the backlight files
17:26:53pamauryactually it's incorrect
17:27:00pamauryqueue_wait_w_tmo() returns event with sys_timeout
17:27:07gevaertsOh
17:27:09gevaertsright...
17:27:21pamauryif you queue_wait_w_tmo(&queue, &evt, tmo); and it times out, then evt.id == SYS_TIMEOUT
17:27:33pamaurywhich makes sense
17:27:35chrisjj50% looks very low for a unit that's been on charge for 36h, but perhaps the battery is near end of life. 'View battery' page 2 says Pwer status: discharging, Battery status: 3.816V, (4.9%) Charger: present
17:27:42gevaertsOK, so I was totally wrong :)
17:28:03*gevaerts now sees that that queue_post() he found is to backlight_queue
17:28:08pamaurychrisjj: so my suspision looks correct, the battery is discharging when plugged, and the device eventually powers off because of low battery
17:28:31chrisjjpamaury, you haven't get got an accurate battery_bench.txt from me.
17:28:51pamauryyou sent me a battery bench file no ?
17:29:16chrisjjI thought not.
17:29:47pamaurygevaerts: so actually the code in sd makes complete sense now
17:30:11pamauryqueue_wait_w_tmo(&sdmmc_queue, &ev, HZ); -> SYS_TIMEOUT after a second if no event (hotswap or usb).
17:30:13 Quit Bilgus (Remote host closed the connection)
17:30:38chrisjjYour suspicion sounds like good news to me. I.e. the voltage tweak solved the BSoPO enough for devices to reach natural BSoPO due to a separete failure to run off external power.
17:30:41 Join Bilgus [0] (~Bilgus@gateway/tor-sasl/bilgus)
17:30:55gevaertsIt makes more sense, yes, but doesn't that now make it write every second?
17:31:13pamaurythus it will (at least on imx233 but I expected other targets), notify idle storage after X seconds of inactivity after some read/write. X is 3 seconds on imx233 currently
17:31:17gevaertsHmm, no
17:31:24gevaertsRight
17:31:30gevaertsYes, that makes sense
17:31:34pamauryyeah
17:32:38gevaertschrisjj: are you playing audio during these runtime tests?
17:33:01chrisjjYes I am playing audio. But no jack inserted.
17:33:05gevaertsok
17:33:24pamauryso notify callback is working as expected, however the nvram stuff is a bit more shaky
17:33:47chrisjjSo/// is 'battery_bench does *not* write every minute' true, false, or unknown?
17:33:54gevaertsYes, I'm not sure what storage activity there normally is on shutdown
17:34:50pamaurythat depends on the battery bench code I believe
17:35:22gevaertsActually, I'm fairly sure that *if* there is io on shutdown, the shutdown is going to happen less than three seconds after that, so nvram won't be written
17:35:43*gevaerts said earlier when battery_bench writes
17:35:51pamauryI ebelieve battery bench properly writes it on shutdown
17:35:56gevaertsIt does
17:36:04gevaertsShutdown, buffer full, idle callback
17:36:09chrisjjI think the're's no doubt the battery_bench code is writing every minute. The doubt is whether these writes are being committed to disc every minute.
17:36:22pamaurychrisjj: it doesn't mater
17:36:35pamaurythose writes end up on disk
17:36:43pamaurythat all what matters
17:36:54gevaertsThere's no doubt the battery_bench does *not* write every minute. It stores to its internal buffer every minute, but it does not *write*
17:36:55pamaury(as long as the device doesn't crash obviously)
17:37:22gevaertsWriting every minute would be stupid and would destroy battery runtime on every spinning disk device
17:37:33chrisjjpamaury, Those writes end up on disc even if there is a crash?? Or angry watchdog reset??
17:38:01pamauryI just said no
17:38:40pamaurybut as long as the device properly shutdown because it runs out of batery, it's written to disk
17:39:18chrisjjOK, then your 'those writes end up on disc' is untrue in event of crash or reset. Got you.
17:41:01chrisjjWe don't know if there is RB shutdown on these BSoPOs. I am assuming angry watchdog reset does not do RB shutdown.
17:41:01 Join skapazzo [0] (~skapazzo@151.9.205.1)
17:41:13chrisjjDid I assuem wrong?
17:42:26pamaurygevaerts: what is eeprom_settings_store() ?
17:43:06pamaurychrisjj: no, watchdog does not shutdown properly
17:43:24pamauryso yes you assume correctly
17:43:46gevaertspamaury: I don't know the details, but only iriver h1x0 has it
17:44:36pamaurygevaerts: I think clean_shutdown() needs to write the nvram settings
17:45:23pamauryok wait
17:45:26pamaury*oh wait
17:45:41gevaertsIn the batt_safe case, yes. Otherwise, I'd say no
17:45:49pamaurySYS_POWEROFF -> clean_shutdown() -> system_flush() -> call_storage_idle_notifys(true)
17:45:58gevaertsHmmm
17:46:40gevaertsRight, so it looks like things work as designed
17:46:58gevaertsWhich is *not* to save stuff on battery low shutdown :)
17:47:18pamauryyes :)
17:47:20gevaertsWhich I think explains everything we see
17:47:52gevaertsChanging that on non-spinning storage *might* be safe, but I'm not convinced
17:49:02pamauryI think the way the code was designed, rockbox force power down only when the battery is really really low and thus spinning will be dangerous
17:49:42gevaertsSpinning takes a surprising amount of power
17:50:04chrisjjSo RB is not saving stuff on battery low shutdown, but what's the evidence that is by design?
17:50:09pamauryit also depends on battery calibration
17:50:19pamaurychrisjj: the code
17:50:20gevaertschrisjj: the code
17:50:24pamaury:D
17:50:25gevaertsif (batt_safe)...
17:50:41chrisjjAh, some different meaning of the word 'design'.
17:51:05pamauryto be fair, that only happens when battery litterally reaches 0%
17:51:30chrisjjWould someone please provide a value for X that makes this statement true: "battery_bench writes every X minutes".
17:51:50pamaurythere is no such value
17:52:09chrisjjSo, not even e.g. 60 minutes?
17:52:20pamauryI think the more relevant question is why don't we power down before 0%, or rather why don't we have some configurable percentage to power down before that
17:52:36pamaurychrisjj: no, only on shutdown and when the storage is active
17:52:56chrisjjMore relevant to deign yes. Not more relevant to testing current code.
17:53:02pamauryif you load a super huge playlist, this will happen regularly
17:53:04chrisjjOK, got you.
17:53:25pamaurystorage takes power, it makes sense to minimize it
17:53:29pamauryespecially during battery bench
17:53:33chrisjjPerhaps you'll recall your advice to me to use battery_bench as a source of runtime measure.
17:53:57gevaertspamaury: isn't that basically the same as redefining 0%?
17:54:07chrisjjZEN testers' Pro Tip: Do not use battery_bench as a source of runtime measure. In event of crash it can be wrong by >60minutes.
17:54:09pamaurywell yes, as long as it does not crash, battery_bench is the best way to measyre runtime
17:54:31gevaertsIn the event of a crash, we are interested in debugging the crash, *not* nin battery runtime
17:54:40pamauryif the device crashes randomly, measure battery runtime is usually the least of your problem
17:54:47chrisjjYour advice was for measuring the time up to a fail :-)
17:55:20pamaurywell I gues it doesn't work unless you use to super huge playlist then
17:55:29chrisjjIt is not about battery runtime. It is about device run time! :-)
17:55:55pamaurygevaerts: not necessarily, if you shutdown at 1%, you cleany save the current config, if you shutdown at 0%, you don't
17:55:57chrisjjI use a 500-track 22hr playlist on Repeat All.
17:56:00pamaury*cleany
17:56:21chrisjj... and still it appears it doesn't work.
17:57:07chrisjjSo, what other options do we have for determining how long a device ran before a BSoPO?
17:57:17pamauryI expect that with the voltage fix it will now work, because it's not crashing anymore
17:57:33chrisjjWhat makes you think it is not crashing any more?
17:58:28 Quit Tristitia (Remote host closed the connection)
17:58:56pamaurybecause of the runtime: 3 or 4 devices, all stopping around 25h, which is expected battery runtime, coupled with the fact that there is a bug in the charging code that lets battery discharge when plugged too long to a charger
17:59:21pamaurythat seems to indicate it powers down simply because the batery is low
18:00
18:00:11pamaurynow the only thing that *may* be wrong is that some part of the code might be confused about running of battery when plugged to a charger
18:02:04chrisjjOK, got it. I'd say we have a non-crash explanation for the BSoOD, but we've not yet shown there are no crashes.
18:02:42pamauryI think four crashes, all around ~25h is *very* unlikely
18:02:49chrisjjI've seen confusion!
18:03:16 Quit elensil (Quit: Leaving.)
18:03:25pamauryyou can debate whether it's a crash or a clean shutdown, but I think it points heavily towards a low battery shutdown
18:04:26*pamaury thinks the best way to know is to fix the charging code
18:04:30chrisjjI wouldn't leave something so important to debate! I'd test it :-)
18:05:34pamaurygevaerts: don't you think it's a little unclean to do an unclean power down at 0% though ? Wouldn't it make sense to at least save a few things at 1% ?
18:05:40*chrisjj thinks the best way to know is to test.
18:05:53pamaurywell stare at your device for 25h
18:06:00chrisjj:-)
18:06:15pamauryand at 24h, give me the battery voltage
18:06:20chrisjjI'd rather record the audio.
18:06:58chrisjjBut really is there no way in RB? E.g. a loging plugin.
18:07:11pamaurychrisjj: I just confirmed the charging bug. I've let my ZEN X-Fi charge for 4h starting at 100%. After 3h, charging times out and battery is discharging
18:07:12chrisjjNeddless to say I don't care about battery drain. I'm not using the battery.
18:07:18chrisjjFast work :-)
18:08:01pamaurySo for me, voltage fix + that explains everything except the "unit N" that has the weird dots and data abort on boot
18:08:57chrisjjYou recall my owrry about charging timeout two weeks back? IIUC you thought then that this occurred during topoff only. Are we saying you've found drain doesn't reset the timeout or something?
18:11:04pamauryYeah, after top off is disables the charger but because of the power architecture of the stmp3700 (which is slightly different from imx233), this causes the player to draw power battery instead of usb
18:11:13pixelmapamaury: isn't any low battery value (even 1%) a bit unsafe because in this low end part it is still very very different depending on the shape (i.e. fitness) of the battery? So unless you want to shutdown at a much higher level and throw away some runtime you still can't be safe writing something to disk before a low battery shutdown?
18:11:16pamaury*power from batery
18:11:24chrisjjGawd! Well, glad to caught it.
18:11:35pamaurypixelma: yeah I guess you are right
18:12:29pamaurystill feels a bit wrong though, because I'm sure the playback code will happily read from storage at 1%
18:13:17pamauryactually I don't know when rockbox shutdowns, it probably doesn't wait for 0%
18:13:20gevaertsIt will, but in cases where that's dangerous that will immediately pull the voltage down and cause a low-battery shutdown
18:13:29*pamaury reads the code
18:16:32pamauryI think it depends on battery_level_shutoff
18:18:18pamauryactually you are right, it may shutdown at more than 0%, but batt_safe will always be false even in this case
18:34:54chrisjjZEN Testers' (Semi-)Pro Tip: Despite imx233 in source '\firmware\target\arm\imx233\creative-zen', ZEN uses STMP3760 and this is /slightly/ /different/ https://www.rockbox.org/irc/log-20170127#18:11:04
18:37:03 Quit The_Prospector|2 (Quit: when in doubt, kernel panic)
18:39:43chrisjjpamaury, It sounds to me like I should test a build from you being Version voltage_fix + Fix 'Charge topoff timeout leads to power sourced from battery not charger' + Mod 'Disable reset by watchdog' + nothing else at all.
18:40:51pamauryI don't see the point of disabling reset. And I don't have a fix for charging code yet
18:42:42 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman)
18:43:40*pamaury thinks Freescale should learn logic, that would simplify there power diagram
18:43:44pamaury*their
18:45:28 Quit athidhep (Quit: athidhep)
18:47:27***Saving seen data "./dancer.seen"
18:48:06pamauryhmmm, I think stmp3700 will require a completely different approach to charging than imx233
18:50:43chrisjjYou previously suggested further test builds to me would have nowdt. The point for me is to eliminate BSoPOs due to crash. Had the last few builds has nowdt, we would not have mistaken (what we now assume to be) the battery low BSoPOs for (what until an hour ago we assumed to be) crash BSoPO, and we wouldn't have wasted a lot of time.
18:51:29chrisjjTLDR; Until we have get proven stable execution, nowdt will save time and confusion.
18:51:48chrisjjd/get/
18:53:21chrisjjPerhap nowdt could be made a System settings option, off by default, allowing it to go in the master and thereby cut the hassle to you of special builds.
18:53:57chrisjjYou can bet I'd find a use for that in production builds for years :-)
18:55:16*chrisjj thinks for now he'll use a different approach to charging: un and replugging the charger even 2.5hrs :-)
18:57:03pamaurynowdt will not be a system setting. At best it can be a debug setting well hidden in debug menu
18:57:04 Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl)
18:58:29pamaurywodz: hey :) did you have time to try anything with audio on nwz ?
18:59:02wodzpamaury: Current desgn is heritage of spinning disk storage. Spinning up disk kills even healthy battery when it is almost empty while playback is sustained for a fair amount of time still.
18:59:32wodzpamaury: Maybe I'll find some time tonight
19:00
19:00:29wodzIt may make sense to change this for flash players
19:05:23 Join alexweissman [0] (~alexweiss@149-160-168-106.dhcp-bl.indiana.edu)
19:06:17chrisjjOops, sorry, I did mean a System Debug setting.
19:16:00 Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr)
19:30:44*chrisjj realises charge bug workaround's un- & re-plug doesn't need to be every 2.5hrs. Every 12hrs will suffice... when it is acceptable for test conditions to include battery powered.
19:31:47*chrisjj starts voltage_fix test runs on four ZENs, planning replugging of charger every 12hrs
19:35:00chrisjjCan plugin code get writes to a file to be actually written to disc? E.g. by closing the file and reopening? Or making some special storage manager call?
19:36:03pamaurychrisjj: I think you misunderstood, writes to file end up on disk. What battery bench does is that it only writes when the storage idle callback is called
19:37:12pamauryactually writes are probably cached but open(), write(), close() most probably flushes to disk
19:38:15gevaertsAs far as I know, writes are cached up to a full sector
19:38:41gevaertsBut you can always call fflush()
19:39:05gevaertsHmm, maybe not
19:41:06 Quit Moarc (Ping timeout: 260 seconds)
19:41:34pamauryI'm not sure we have fflush()
19:41:40pamaurybut possibly close() flushes
19:41:47pamaurywith have storage flush
19:41:50gevaertsclose() definitely does
19:42:19pamaurythen I guess open(), write(), close() is good enough
19:42:22 Join Moarc [0] (~chujko@a105.net128.okay.pl)
19:42:23gevaertsWe don't have a filesystem cache as such
19:42:28pamauryit's what batery bench does
19:42:57pamauryah yeah you're right, it's per file cache for the current sector
19:44:04gevaertsI'm not even sure if it *really* caches the sector in the way you'd normally understand that, or if it just has that because you need to read sectors from disk if you want to support appending on non-full-sector files
19:47:50pamaurywell you want to cache a sector just because if you read one byte at a time, you want to be fast, same for writes
19:48:31gevaertsYou can't really read one byte at a time
19:48:33pamauryit's the minimal amount of caching you need in a sane design
19:48:45pamauryyou could read a sector, take one byte and through it away ;)
19:48:49pamaury*throw
19:48:52gevaertswell yes :)
19:49:54 Quit GodEater (Quit: Coyote finally caught me)
19:52:49 Quit petur (Quit: Leaving)
19:53:14 Quit wodz (Ping timeout: 240 seconds)
19:54:13 Join GodEater [0] (~whoknows@176.253.28.187)
19:54:13 Quit GodEater (Changing host)
19:54:13 Join GodEater [0] (~whoknows@rockbox/staff/GodEater)
19:54:51__builtinafaik we don't do any I/O buffering
19:55:48 Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl)
20:00
20:06:36 Join alexweis_ [0] (~alexweiss@149-160-168-106.dhcp-bl.indiana.edu)
20:07:27 Quit alexweissman (Ping timeout: 240 seconds)
20:14:38 Quit alexweis_ (Read error: Connection reset by peer)
20:25:36jhMikeSchrisjj: fsync()
20:38:58 Quit uwe_android__ (Remote host closed the connection)
20:38:58 Quit uwe_mobile__ (Remote host closed the connection)
20:47:28***Saving seen data "./dancer.seen"
20:48:35 Join VargIVeum [0] (6d6804dd@gateway/web/cgi-irc/kiwiirc.com/ip.109.104.4.221)
20:49:02 Quit VargIVeum (Client Quit)
21:00
21:25:17 Join alexweissman [0] (~alexweiss@149-160-168-106.dhcp-bl.indiana.edu)
21:28:10 Join mutnai_ [0] (6db91733@gateway/web/freenode/ip.109.185.23.51)
21:29:43 Quit alexweissman (Ping timeout: 240 seconds)
21:33:32 Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr)
21:34:26lebelliumpamaury: when do you think you'll have time to progress on the nwz port?
21:36:48pamaurythis week-end
21:37:55lebelliumgreat
21:38:49chrisjjpamaury, I think I understood correctly, that writes to file end up on disk /provided/ no crash in the meanwhile.
21:39:52pamaurychrisjj: where meanwhile == in the next millisecond or so
21:39:56chrisjjWhat I'm asking is can plug-in code get writes to file actually written to disc upon request.
21:40:13chrisjjOh? Millisecond?
21:40:21pamaurywrite is a write, you write to disk
21:40:42pamaurythere is avery small amount of buffering involved but if you open(), write(), close(), it's on disk
21:40:53pamaurywhat I already explained is that this *not* what battery bench does
21:41:09pamaurybattery bench only does open(), write(), close() on storage idle callback
21:41:54pamauryand it registers a storage idle callback every minute or something like that, but that doesn't mean the callback is called every minute
21:42:55chrisjjI'm not asking about battery_bench, but about plug-in code in general.
21:43:24chrisjjSo I take it 'writes are cached up to a full sector' is true, meaning writes are in general vulnerable to loss on crash indefinitely, but close() puts it on disc for sure, within ms.
21:43:52 Quit furrywolf (Read error: Connection reset by peer)
21:44:02pamauryplugin is no different from any other code, it uses open, write and close
21:44:15pamaurydepends on how it's implemented
21:44:17 Join furrywolf [0] (~randyg@107.25.30.188)
21:44:31pamaurybattery bench is one way of implementing things
21:44:33pamaurythe right way
21:45:44chrisjjYou're saying it depends on how close() is implemented?
21:45:56pamauryno it depends on how the plugin is implemented
21:46:04chrisjjGreat. Thanks.
21:46:24pamaurythere is fsync also to force a flush to disk, in case where you don't want to close the file
21:47:10chrisjjThen what I'd like is a plug-in that does what battery_bench says it does do but doesn't do. Logs "in a file every minute."
21:47:23__builtinfsync() isn't exposed in the plugin API though
21:47:27chrisjjGot it, and thanks jhMikeS,
21:48:39pamaurythen modify battery bench to log every minute instead of registering an idle callback
21:51:20chrisjjIndeed that's where I'd start. And though it has been said here that makes it useless for its intended purpose, ISTM that's untrue for flash-based devices.
21:51:22 Quit mutnai_ (Quit: Page closed)
21:51:31 Quit mutnai (Quit: Page closed)
21:52:14dyspamaury: the blackfin was stronger than the rpi SoC, but I eventually found out when I power it up with the DO line grounded, the boot rom appears to halt and tristate everything -> PROFIT
21:52:16__builtinwhat is `ISTM' supposed to mean?
21:53:39lebellium__builtin: are you really reading?!
21:54:49chrisjj"It Seems To Me" https://www.google.co.uk/search?espv=2&q=ISTM+acronym
21:54:59pamaurychrisjj: it doesn't matter what you think, battery_bench does what it is intended for: evaluating the maximum battery life, whatever the type of storage
21:55:17pamaurydys: cool :)
21:56:00__builtinhttps://www.rockbox.org/wiki/IrcGuidelines: "Use clear, grammatical, correctly-spelled English."
21:56:13chrisjjpamaury, Does https://www.rockbox.org/tracker/task/9155 'written when the disk is active anyway' still apply?
21:57:52pamaurychrisjj: are you reading what we say ?
21:57:57chrisjjYup.
21:58:04chrisjjDoes that still apply?
21:59:33pamauryWe just spend many lines explaining to you that battery bench only writes when the disk is active
21:59:53chrisjj'Cos if so, it seems to me that battery bench is going to write every time a track longer than 60s is read from store.
22:00
22:01:08pamaury?
22:01:19 Join edhelas [0] (~edhelas@145.133.43.230)
22:01:41chrisjjStore being 'disk' in this case.
22:02:34pamauryI'm not following your logic here
22:02:36chrisjjThis might explain why your battery benchmarking procedure works for the discharge part, but fails (here every time) for the charge part when there is a BSoPO.
22:02:48chrisjjOK, sorry to be unclear.
22:03:08 Join Senji_ [0] (~Senji@85.187.103.250)
22:03:13dyspamaury: we have strings! however, curiously, the first 400kB read ff/00. I hope it's not some lock bit preventing readout
22:04:57pamaurydys: cool :) Even the very first bytes ? I need to double check what the manual says about booting from SPI. Do you have the whole flash dump ? Can you upload it somewhere ?
22:04:57chrisjjIf battery bench writes /every/ time the disk is active, and the disc is active every time a track is loaded, and a track is loaded each time one completes (assuming the large playlist that your procedure requires), then ...
22:05:14pamaurychrisjj: that's not how buffering works, at all
22:05:14gevaertsThen your assumptions are incorrect
22:05:45 Quit michaelni (Ping timeout: 258 seconds)
22:05:46chrisjjWrite buffering, or track buffering?
22:05:47 Quit Senji (Ping timeout: 240 seconds)
22:06:22pamaurychrisjj: although I'm not an expert of the (very complex) buffering code, it basically loads as much much as possible, then decodes when needed, and only rebuffers on low watermark. Basically it minimizes disks access and reads as much as it can at a time
22:06:38chrisjjThat's my understanding too.
22:07:02chrisjjAnd since my tests are feeding 2.4Gb of tracks, the buffering must at some time load tracks in play.
22:07:17gevaertsStrictly speaking, no
22:07:31gevaertsParts of tracks, yes
22:07:32chrisjjBut I recognise that if it has a very low watermark...
22:07:43chrisjj.. (though goodness knows why on flash)...
22:07:54chrisjj... then disc activity is still rare.
22:08:09pamaurywith compressed formats, you don't need to rebuffer that much
22:08:10chrisjjParts of tracks is fine.
22:08:12gevaertsYes, which is *exactly* the opposite of what you were saying
22:08:15gevaertsPlease stop trolling
22:08:45pamauryA typical 3/4MB song will last several minutes. The ZEN has 32MB of memory, you can store almost an hour compressed in RAM
22:08:46chrisjjSo, is there anything on e.g. System > Debug that shows disc activity? I'll see what it is doing in these tests.
22:09:14chrisjjMeanwhile if anyone has a better explanation for discharge succeeding and charge failing, I'd love to hear it.
22:10:05chrisjjI'm using 5Mb tracks already compressed.
22:11:23chrisjjHow much is stored is not relevant to how frequently load occurs. What is relevant is how much is between low and high watermark.
22:12:18pamauryif you follow the logic up to the end, the watermark must be pretty low, otherwise it doesn't make sense
22:12:46__builtinlebellium: I've found that reading /some things/ is a waste of time and effort :P
22:13:53chrisjjI've seen no logic that says the watermark /must/ be low. Flash would not require it. Perhaps it's low as inherited from real disc requirements.
22:14:04prof_wolfffwodz: just seen your log on nano2g USB probes, at this moment i am out of home so i have no access to my nano2g, i hope to do extensive testing tomorrow at home, anyway... what i see at first look is a bunch of 'hw' errors, it goes forward, at last the host tries to reset the USB device but there is no response from the device and everything ends at this point, the 'hw' errors could come from USB driver, NAND driver or HW itself
22:14:04prof_wolfffbut i am really worried because in any case USB bus should reset and enumerate but really it fails to do that, it is not easy to debug this thing, while developing i was using serial debug to do that, i suppose you cannot do that (you need a modified cable to read serial tx), so any clue will be useful for me, i.e. what happens after USB copy fails? i assume there is no panic, right? does HID works well? does RB works well is you di
22:14:04prof_wolfffsconnect USB or just everything hangs?
22:14:11chrisjjCan't I just see from Debug when the buffer is loaded? That would answer the mystery.
22:14:59pamaurythere is some buffering debug screen somewhere I think
22:15:11pamaurychrisjj: it still makes sense on flash, despite what you think
22:15:22chrisjjYup, I've seen it mentioned in IRC but not found it.
22:15:37pamauryread/write require the flash and controller and clocks to be powered, you want to minimize that
22:16:29chrisjjSure, but flash 'spin-up' is tiny compared to disc spin-up, in power consumption terms.
22:17:18amazoniantoadIs there something like itunes for rockbox?
22:17:49scorcheamazoniantoad: in what sense?
22:17:52__builtinamazoniantoad: not really
22:18:07amazoniantoadA library manager I guess. I'd like to have a gui for managing my playlists and stuff
22:18:18scorchenot specifically for rockbox, but there are plenty of those sorts of programs around
22:18:34amazoniantoadWill the work with rockbox?
22:18:34 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at)
22:18:36amazoniantoadthey*
22:19:10scorcheamazoniantoad: you get to try them and find out!
22:19:17gevaertsscorche: did you see the current state of the forums?
22:19:26scorcherockbox isnt anything special - files are files on disk, etc
22:19:39gevaertsamazoniantoad: if you're *really* bored and motivated, it's actually not impossible to get itunes to work with rockbox
22:19:39scorchegevaerts: nope
22:19:49gevaertsscorche: some database issue now
22:19:58scorchegevaerts: yes - i see that now :)
22:20:03scorchethanks
22:20:07amazoniantoadWell I was considering writing a program to retain my playlists while still sorting the songs to the appropriate bands/albums
22:20:16amazoniantoadBut I'm hoping some gui like iTunes will do that for me.
22:20:23pamaurychrisjj: I don't see the point. When you have the choice between one tiny power up, one big read, power down, or multiple tiny power up, one small read, and power down. The first option is still the best
22:21:08chrisjjLet's not mention Shuffle :-)
22:21:15scorcheamazoniantoad: there likely is such a thing in existance, but it isnt really the focus of this channel
22:21:19gevaertsThe thing is that the playback and buffering system is complex enough that at any given time it's hard to find someone who understands enough of it. Clearly what we want is *two* of those systems
22:21:40chrisjjRegardless, do you have any other idea why charging battery_bench is failing, or any guessed workaround?
22:21:48amazoniantoadscorche, of course. I just though I'd ask. Thanks for the answers guys. This channel is one of the highest quality irc channels I've come across.
22:21:56amazoniantoadGreat community here.
22:23:27chrisjjpamaury, actually the better question is: Have you ever got the charging part of your procedure here https://www.rockbox.org/wiki/CreativeZENPort#Battery_Calibration to work?
22:24:15scorchegevaerts: its back
22:24:20gevaertsYay!
22:24:45scorchegevaerts: feel free to ping me when you notice this
22:25:03scorchei am bouncing the server often enough, but often fail to actually check that it came up cleanly
22:25:25gevaertsscorche: oh, I do, usually when you're asleep :)
22:25:51scorcheoh - so you did
22:26:11pamaurychrisjj: I'm pretty sure I did
22:26:22chrisjjOK, nice to know.
22:28:45chrisjjI'll try this on voltage_fix expecting no BSoPO to wipe the battery_bench buffer, and then I'll manually shut down to write it to disk. We'll see.
22:31:59chrisjjpamaury, on a different subject, I've found the unit that acted different on one of your attempted backlight flash fix attempts also acts different on backlight wake on power source going charger -> battery.
22:32:44chrisjjIt doesn't wake.
22:33:41chrisjj(Mostly.)
22:35:24chrisjjSo I wonder... Did you find out whether RB code can even detect whether the RAM is 32 or 64Gb?
22:36:13chrisjjs/Gb/Mb/
22:36:42chrisjj(This unit (G) is one of those on the soak test so I've not yet reflashed it to determine whether it is another 64b unit.)
22:36:58 Join gbl08ma [0] (~gbl08ma@ec2-52-23-151-127.compute-1.amazonaws.com)
22:37:38pamauryrockbox can detect the size but currently it only uses the size set at compile time. Changing that is not trivial
22:42:39prof_wolfffTheSeven: about nano2g, i did some research on disassembling s5l8702 OF, some of your IDA scripts help me to manage the EFI modules on s5l8702, but really i have not info about s5l8701 and ATM i have not much time so i am a bit lazy to reverse engineering, I would appreciate if you can locate and share any info you have about s5l8701
22:47:29***Saving seen data "./dancer.seen"
22:51:51 Join VargIVeum [0] (6d6804dd@gateway/web/cgi-irc/kiwiirc.com/ip.109.104.4.221)
22:53:38 Quit VargIVeum (Client Quit)
23:00
23:01:00Bilgusamazoniantoad, how did your bluetooth project work out
23:03:13amazoniantoadBilgus, not quite done. I was never able to get around to this final step. Will have time in a little bit
23:03:25wodzprof_wolfff: After usb failing the player is stuck in usb screen. The only reaction on physical cable disconnect is backlight on. The only way to recover is hard reset. After reset booting takes considerably longer (I assume apple boot code does some ftl cleanup). Disk mode works flawlessly.
23:03:33amazoniantoadTrying to finish up my program to rip songs from spotify. TAILS is being a bitch though.
23:03:49amazoniantoadI guess it's just all locked down.
23:04:17amazoniantoadBilgus, I plan on finishing it today though.
23:04:53BilgusLOOKFOR saver2 by zigzag
23:05:37 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51)
23:05:53amazoniantoadoh nice.
23:06:16chrisjjpamaury, OK, so RB could be inadvertently sensitive to RAM size.
23:06:20scorchelets not talk about ripping songs from spotify here...
23:06:23amazoniantoadWell I don't know if spotify can see what's going on with that program spotify-ripper. So I'm trying to write up some additional security just in case.
23:06:44amazoniantoadscorche, oh I didn't mean spotify the music app. I meant something totally unrelated to the spotify music streaming service.
23:06:50amazoniantoadSpotify is what we call my uncle joe.
23:06:56amazoniantoadIt's his nickname from childhood.
23:07:02 Join Exo_ [0] (45786f4c@gateway/web/freenode/ip.69.120.111.76)
23:07:05scorcheamazoniantoad: either way, it doesnt have anything to do with Rockbox...
23:07:12dysfan service… http://ansel.ydns.eu/~andreas/getting_serious_with_a_blackfin_port.jpg
23:07:18amazoniantoadI'll make sure to tell my uncle joe.
23:07:50wodzdys: I like that!
23:07:59Exo_Heya folks... anyone familiar with the H340 and the iflash adapters?
23:08:31wodzpamaury: Could you point me to instruction how to install bootloader on nwz?
23:10:57mutnaianyone here with nw-zx100 ?
23:14:22pamaurywodz: writing instructions...
23:14:45wodzpamaury: Is toolchain rework commited or it sits somewhere on gerrit?
23:17:40wodzfound it
23:20:16prof_wolfffwodz: thanks! i will test it tomorrow and send you my findings
23:20:48wodzprof_wolfff: If you want me to test something, ping me
23:22:00pamaurywodz: pamaury/951cbe4e361da46a8ff9027b21381cdd">https://gist.github.com/pamaury/951cbe4e361da46a8ff9027b21381cdd
23:22:19pamaurywodz: it's in the NWZ commit I think
23:22:21 Quit amayer (Quit: Leaving)
23:23:13pamaurywodz: what is your device again ?
23:23:26prof_wolfffok, first i will test it using the latest HEAD and if i cannot find the bug i will send you a debug version to try to locate what is happening
23:23:36prof_wolfffwodz: ^
23:23:37wodzpamaury: yeah, you should untangle rockboxdev.sh change from that and just commit.
23:23:43wodzpamaury: e474
23:23:54wodzprof_wolfff: ok
23:25:28pamaurywodz: I'm not i've added E470, let me check, it's kind of trivial right now but not sure it's in the commit
23:26:33pamauryyep, give me 5min to add it
23:27:32wodzpamaury: I compile toolchain now so you have some time :P
23:27:37pamauryok :)
23:30:35fs-bluebotBuild Server message: 3New build round started. Revision d4303ac, 255 builds, 15 clients.
23:31:58 Quit mutnai (Quit: Page closed)
23:32:33pamaurywodz: I updated gerrit
23:32:42wodzgreat
23:33:30pamauryI tried to compile the bootloader for NWZ-E470 and it works, so you should not encounter any problem
23:33:43pamaurybut if you want to speed up thing, I can send you a prebuilt one
23:34:09 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507])
23:34:50wodzpamaury: Please send as compiling toolchain will take a while
23:36:24dys*sigh* … H74R … The markings on tiny chips are really unforgiving (pamaury)
23:37:17dysIf anyone has an idea what this critter could be, I'd be highly interested
23:37:36dys(8-pin case, suspected flash)
23:37:55pamaurywodz: https://www.dropbox.com/s/f49huqibakz9uju/NW_WM_FW_nwze470.UPG?dl=0
23:38:45pamaurydys: usually on small flashs, the marking does not even correspond to the part name, or can be a small part of it, it's going to be hard :-/ are you sure it's on the spi bus ? could it be i2c ?
23:39:07dyspamaury: can the blackfin boot from i2c, too?
23:39:28pamaurynot sure, I'm checking
23:41:08furrywolfok. I got a new microsd card. who wants to figure out why the original partition table breaks rockbox? (assuming this card does the same thing as the last one, of course)
23:41:17wodzpamaury: http://paste.debian.net/911017 :-/
23:41:24pamaurydys: apparently not, it supports uart, link port, emmc, sd and spi
23:42:01pamaurywodz: install libmpfr-dev, libgmp-dev and libmpc-dev
23:42:07fs-bluebotBuild Server message: 3Build round completed after 691 seconds.
23:42:08fs-bluebotBuild Server message: 3Revision d4303ac result: All green
23:42:14wodzThere was a site to decode smd part *markings* but can't remember the url
23:44:20furrywolfcan I assume the first megabyte of the card will contain all relevant info to debugging this?
23:46:21wodzfurrywolf: mbr + partition table is fraction of this
23:46:42furrywolf+fat, since someone was suspecting filesystem oddness
23:51:44furrywolfok, it's currently not working. other than doing the steps to make it work, and taking images every step, anything I should do?
23:52:40wodzpamaury: Any special way to write scripts run from 'debug tools' menu?
23:53:05furrywolf... ok, I might have just solved it, and it's a lot easier than I thought. cfdisk and fdisk are disagreeing on the partition type.
23:53:19furrywolfcfdisk is saying it's fat32, fdisk says it's ntfs.
23:53:41furrywolfI'm guessing it's set to something funky, and rockbox is ignoring it.
23:54:06wodzfurrywolf: What capacity is this card?
23:54:49furrywolfyep, that was it.
23:55:09pamaurywodz: no, just make sure they work with sh, and not bash
23:55:36furrywolf128gb, originally formatted with exfat. cfdisk shows it as being fat after reformatting it, but fdisk still says ntfs. I went by cfdisk's information before. obviously the partition type is funky and/or cfdisk is broken.
23:55:48wodzpamaury: Does it need to be decorated with #!/bin/sh or something?
23:56:02furrywolfchanging the partition type to 0b makes rockbox read it.
23:56:29wodzfurrywolf: partition type and filesystem are two different things
23:56:43pamaurywodz: no, I run it with "sh <script>"
23:57:27furrywolfyes. I am aware of this. when I reformatted it before, after it didn't work, I checked with cfdisk, which showed the partition type as fat32, so I assumed mkdosfs had helpfully changed the partition type as well. fdisk shows it doesn't. I don't know what cfdisk is smoking.
23:57:46furrywolfin any case, it's not a rockbox issue, it's a cfdisk issue.
23:58:18wodzpamaury: Where is 'user visible' part of flash mounted from player pov?
23:58:33wodzpamaury: I mean where can I log output of commands

Previous day | Next day