--- Log for 27.01.117 Server: nylund.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 22 days and 3 hours ago 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.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.47 # damn, the Qt folks have some interested twist 01.05.36 # they 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.56 # then in 5.7, the decide that qstyleoptionviewitem should have all the fields from v4 and stop this version mess 01.06.00 # and deprecate qstyleoptionviewitemv4 01.06.30 # which 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.42 # that'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.21 # pamaury, Thanks. Which difference http://i.imgur.com/nGqKGVg.png is the RAM size? 02.01.00 # qstyleoptionviewitem 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.03 # __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.46 # <__builtin> chrisjj: 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.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.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.33 # Build 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.38 # Build Server message: 3Build round completed after 725 seconds. 05.21.39 # Build Server message: 3Revision 58b849c result: All green 05.22.13 # pamaury: I have the SPI testpoints figured out, but not yet found an accessible reset pin to tristate the blackfin SPI port 05.22.44 # pamaury: 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.12 # (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.04 # [Saint], anyone else interested G#1541 is up 05.53.05 # 3Gerrit review #1541 at http://gerrit.rockbox.org/r/1541 : 3Advanced Auto-Ranging Time Formatting For Menus (hh:mm:ss:mss) by William Wilgus 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.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.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.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.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.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.09 # Bilgus: do you think you could have a look at https://www.rockbox.org/tracker/task/10363#comment43861 ? 11.59.29 # it's a bug with chessbox and you have worked a lot on plugins now ;) 12.06.38 # chrisjj: re difference: the RAM size is not written anywhere. It involves putting 4 fields together in an equation. 12.06.38 # In 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.01 # pamaury: Pulling the unidentified testpoints low via 1kΩ also didn't result in a reset :-/ 12.25.18 # all 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.29 # dys: can you sniff the wires when the SoC is starting ? 12.37.53 # ie 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.39 # I had this problem once and that the only solution I came up with when even pulling the pins doesn't work. 12.39.13 # I 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.17 # i 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.24 # ah 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.08 # it 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.27 # yeah unless you have a 100Mhz+ uc it doesn't look easy to sniff it 12.47.32 # or fpga 12.48.14 # also, if the blackfin switches the spi to multi-pin data out it adds another problem 12.48.14 # if 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.29 # multi-pin data ? what is that ? 12.49.07 # the spi used supports parallel output on four lines IO1…IO4 in the pinout 12.49.41 # the chips on x86 mainboard are routinely used in this mode 12.49.44 # it's a pita to sniff, i can tell 12.51.01 # lunch break over, need to cycle to work now… afk for another 6 hours 12.51.26 # ah, I though spi was one wire of data onl 13.00.17 Join petur [0] (~petur@rockbox/developer/petur) 13.06.09 # pamaury, 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.22 # yes it is written by the RAM init code that runs really early at boot 13.21.29 # but 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.29 # Is 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.14 # chrisjj: sure, we do that on ipodvideo 13.28.39 # wodz: doesn't rockbox assume compile timed defined RAM amount ? 13.28.44 # *compile time 13.29.20 # pamaury: ask gevaerts about details but a few years ago 32 and 64MB build of ipodvideo were merged into one 13.29.58 # ah, I remember we indeed had two builds. I will look at the code 13.30.06 # although 32MB is already plenty 13.30.39 # I wouldn't worry about 32MB considering that devices freeze randomly :-) 13.32.08 # Plenty means only that there's no /good/ reason for Rockbox to detect the amount of available RAM :) 13.32.14 # wodz: What devices freeze randomly? 13.32.24 # chrisjj: yours? 13.32.27 # No. 13.33.06 # On the current build, they often BSoPO after about 22h. 13.33.33 # even with voltage fix ? 13.33.33 # I 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.40 # chrisjj: Whatever, your units tend to have some problems and using just half of ram is the smallest 13.34.55 # Yes. On the current build (8fec364f6-170125 voltage fix g1533), they often BSoPO after about 22h. 13.34.56 # 3Gerrit review #1533 at http://gerrit.rockbox.org/r/1533 : 3zen/zenxfi: adjust maximum emi voltage by Amaury Pouly 13.35.39 # I thought you said they were working 13.35.55 # isn't 22h like empty battery anyway ? 13.36.12 # pamaury, I think he wasn't referring to my Unit N, but even if he was, most Unit N fails are data aborts. 13.36.17 # devices tend to power off after they run out of juice 13.36.50 # pamaury, I said there were working while they were working. That was for the first few hours. 13.37.54 # 22h 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.03 # wodz: 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.47 # if they only crash after 20h, that's an improvement 13.42.02 # I'll send you another build with any kind of frequency and voltage scaling disabled to see what happens 13.48.59 # chrisjj: https://www.dropbox.com/s/atgauqu26zpyf8s/firmware_zen_nodfs.nk?dl=0 (bootloader) 13.49.00 # and https://www.dropbox.com/s/ldac8l6ci8jpk33/rockbox_zen_nodfs.zip?dl=0 13.49.00 # pamaury, 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.19 # If the hardware does not map that RAM twice in that way, different approaches will be needed 13.53.06 # chrisjj: 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.13 # gevaerts: I see 13.53.17 # looks like a hack anyway 13.53.57 # on 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.06 # chrisjj: 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.05 # Oh, it's a massive hack 13.59.29 # But it achieved the goal in less than ten lines of code 14.01.15 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 14.01.37 Quit wodz (Client Quit) 14.01.41 # does 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.23 # pamaury, 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.21 # pamaury, 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.12 # Does it always last exactly that long (like +- 5%?) 14.35.44 # when 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.03 # Bilgus, I don't know if it crashes. The BSoPO may or may not be due to a crash. 14.53.11 # Times are: 14.53.16 # Unit P: After 32h 30m, running 14.53.22 # Unit L: After battery_bench 26h12m and Running Time 25h44m, BSoPO 14.53.28 # Unit G: After battery_bench 28h06m and Running Time 27h25m, BSoPO 14.53.34 # Unit Q: After battery_bench 28h43 Running Time 26h03m, Creative charging screen (black except for battery icon in top right) 14.55.41 # FTR, that's for build 8fec364f6-170125 (voltage fix) on charger-powered Creative ZENs. Which RAM variant these are is unknown. 14.58.16 # huh so battery bench is still running after this black screen or how are you calculating runtime? 15.00.52 # ZEN 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.54 # 3Gerrit review #1533 at http://gerrit.rockbox.org/r/1533 : 3zen/zenxfi: adjust maximum emi voltage by Amaury Pouly 15.02.02 # Bilgus, 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.25 # what should a black screen of power-off be? I mean if the device powers off the screen goes dark 15.05.04 # Can you suggest other cause for the difference between battery_bench's last entry and Running Time? 15.05.53 # maybe one thing doesn't get kept/written as often 15.07.33 # ah 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.39 # Greatest discrepancy is 2h40m. 15.09.41 # chriss 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.58 # I haven't. 15.10.44 # that would pretty well answer the question without having to babysit the damn thing 15.10.51 # battery_bench writes every minute. Won't this will spin up the 'disc', and so get Running Time flushed to disc? 15.11.11 # you'd think? 15.11.17 # :-) 15.11.38 # For starters, battery_bench does *not* write every minute 15.11.47 # That would make it entirely useless 15.12.05 # So how often does it write? 15.13.29 # conversely If bench were running don't you think that running time would keep incrementing 15.13.29 # (And if true, would someone please correct "# This plugin will log your battery performance in a # file (//battery_bench.txt) every minute.") 15.13.41 # When 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.51 # I believe on disk access (which happen during rebuffer anyway) 15.14.28 # It records data every minute. Writing that to disk every minute would distort the results enough to make them worthless 15.14.33 # rebuffering for playback I mean 15.14.49 # gevaerts, Wow. That's really disappointing. Thanks for the info. 15.15.10 # Yes, it's very disappointing that it works in a sensible way. We should fix that 15.22.36 # pamaury, note the above re relying on battery_bench to record the runtime up to a BSoPO or crash. 15.23.26 # Bilgus, you'd think! :-) 15.26.40 # I 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.08 # At least in the storage spinup callback 15.31.04 # Which storage driver are you looking ar? 15.36.24 # Hmmm 15.38.02 # pamaury: 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.36 # At 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.57 # If the storage idle callbacks aren't called near shutdown, that could cause what chrisjj is seeing 15.58.34 # gevaerts, 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.37 # How frequent is this storage idle callback? 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.45 # PAMAURY: ill have a look at chessbox in a day or two 16.36.55 Quit Bilgus_ph (Remote host closed the connection) 16.46.39 # gevaerts: 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.14 # I 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.43 # chrisjj: 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.51 # and maybe this trick doesn't work on stmp3700 16.48.59 # which means your battery charges and then discharges 16.49.05 # and then the device powers down 16.50.29 # actually 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.09 # pamaury: I'd expect it to be called on shutdown as well, but I didn't find that 16.58.06 # why ? it doesn't really make sense 16.58.16 Join furrywolf [0] (~randyg@107.25.30.188) 16.59.09 # I 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.40 # I might be wrong of course. Callback hooks are easy to miss 17.07.36 # I 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.47 # the code in settings.c is a bit confusing 17.09.32 # damn, why people don't comment public API x-( 17.09.54 # what is status_save() and settings_save(); 17.11.01 # gevaerts: do we actually store ALL settings to NVRAM on some targets ? 17.12.16 # No, definitely not 17.12.36 # IIRC nvram is 44 bytes on those systems that actually have it for real 17.12.39 # also seriously rtc_read(0x14+i), it really looks like HAVE_RTC_RAM == I_HAVE_FUCKING_ARCHOS 17.12.55 # Yes :) 17.13.36 # pamaury, re storage commits, I'd be interested to know that value of that X. 17.14.02 # it doesn't matter, it's a few seconds 17.15.29 # gevaerts: when is SYS_TIMEOUT sent ? 17.15.46 # According to my grepping when the backlight goes off 17.16.32 # pamaury, re battery, I have one (P) that I believe* to have been running for 36h. 17.16.42 # * I now have no reliable way I know to find the runtime of a device from the device itself 17.19.59 # gevaerts: 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.12 # Ah, 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.50 # pamaury: I'm assuming it was something that's done every now and then, but not too often... 17.20.55 # This means the only run that survived past 29hrs was a faulty test. 17.21.24 # chrisjj: did you see my comment/question on battery ? 17.21.45 # Yes. My [16:16] is the answer. 17.23.33 # Answering 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.38 # it'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.15 # gevaerts: probably SYS_TIMEOUT is not very well named or deserves a comment 17.25.57 # I fail to see why so many things are related to backlight timeout, it doesn't make sens 17.26.37 # I agree, but I suspect it probably never meant to be used outside the backlight files 17.26.53 # actually it's incorrect 17.27.00 # queue_wait_w_tmo() returns event with sys_timeout 17.27.07 # Oh 17.27.09 # right... 17.27.21 # if you queue_wait_w_tmo(&queue, &evt, tmo); and it times out, then evt.id == SYS_TIMEOUT 17.27.33 # which makes sense 17.27.35 # 50% 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.42 # OK, so I was totally wrong :) 17.28.03 # * gevaerts now sees that that queue_post() he found is to backlight_queue 17.28.08 # chrisjj: so my suspision looks correct, the battery is discharging when plugged, and the device eventually powers off because of low battery 17.28.31 # pamaury, you haven't get got an accurate battery_bench.txt from me. 17.28.51 # you sent me a battery bench file no ? 17.29.16 # I thought not. 17.29.47 # gevaerts: so actually the code in sd makes complete sense now 17.30.11 # queue_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.38 # Your 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.55 # It makes more sense, yes, but doesn't that now make it write every second? 17.31.13 # thus 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.17 # Hmm, no 17.31.24 # Right 17.31.30 # Yes, that makes sense 17.31.34 # yeah 17.32.38 # chrisjj: are you playing audio during these runtime tests? 17.33.01 # Yes I am playing audio. But no jack inserted. 17.33.05 # ok 17.33.24 # so notify callback is working as expected, however the nvram stuff is a bit more shaky 17.33.47 # So/// is 'battery_bench does *not* write every minute' true, false, or unknown? 17.33.54 # Yes, I'm not sure what storage activity there normally is on shutdown 17.34.50 # that depends on the battery bench code I believe 17.35.22 # Actually, 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.51 # I ebelieve battery bench properly writes it on shutdown 17.35.56 # It does 17.36.04 # Shutdown, buffer full, idle callback 17.36.09 # I 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.22 # chrisjj: it doesn't mater 17.36.35 # those writes end up on disk 17.36.43 # that all what matters 17.36.54 # There'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.55 # (as long as the device doesn't crash obviously) 17.37.22 # Writing every minute would be stupid and would destroy battery runtime on every spinning disk device 17.37.33 # pamaury, Those writes end up on disc even if there is a crash?? Or angry watchdog reset?? 17.38.01 # I just said no 17.38.40 # but as long as the device properly shutdown because it runs out of batery, it's written to disk 17.39.18 # OK, then your 'those writes end up on disc' is untrue in event of crash or reset. Got you. 17.41.01 # We 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.13 # Did I assuem wrong? 17.42.26 # gevaerts: what is eeprom_settings_store() ? 17.43.06 # chrisjj: no, watchdog does not shutdown properly 17.43.24 # so yes you assume correctly 17.43.46 # pamaury: I don't know the details, but only iriver h1x0 has it 17.44.36 # gevaerts: I think clean_shutdown() needs to write the nvram settings 17.45.23 # ok wait 17.45.26 # *oh wait 17.45.41 # In the batt_safe case, yes. Otherwise, I'd say no 17.45.49 # SYS_POWEROFF -> clean_shutdown() -> system_flush() -> call_storage_idle_notifys(true) 17.45.58 # Hmmm 17.46.40 # Right, so it looks like things work as designed 17.46.58 # Which is *not* to save stuff on battery low shutdown :) 17.47.18 # yes :) 17.47.20 # Which I think explains everything we see 17.47.52 # Changing that on non-spinning storage *might* be safe, but I'm not convinced 17.49.02 # I 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.42 # Spinning takes a surprising amount of power 17.50.04 # So RB is not saving stuff on battery low shutdown, but what's the evidence that is by design? 17.50.09 # it also depends on battery calibration 17.50.19 # chrisjj: the code 17.50.20 # chrisjj: the code 17.50.24 # :D 17.50.25 # if (batt_safe)... 17.50.41 # Ah, some different meaning of the word 'design'. 17.51.05 # to be fair, that only happens when battery litterally reaches 0% 17.51.30 # Would someone please provide a value for X that makes this statement true: "battery_bench writes every X minutes". 17.51.50 # there is no such value 17.52.09 # So, not even e.g. 60 minutes? 17.52.20 # I 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.36 # chrisjj: no, only on shutdown and when the storage is active 17.52.56 # More relevant to deign yes. Not more relevant to testing current code. 17.53.02 # if you load a super huge playlist, this will happen regularly 17.53.04 # OK, got you. 17.53.25 # storage takes power, it makes sense to minimize it 17.53.29 # especially during battery bench 17.53.33 # Perhaps you'll recall your advice to me to use battery_bench as a source of runtime measure. 17.53.57 # pamaury: isn't that basically the same as redefining 0%? 17.54.07 # ZEN 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.09 # well yes, as long as it does not crash, battery_bench is the best way to measyre runtime 17.54.31 # In the event of a crash, we are interested in debugging the crash, *not* nin battery runtime 17.54.40 # if the device crashes randomly, measure battery runtime is usually the least of your problem 17.54.47 # Your advice was for measuring the time up to a fail :-) 17.55.20 # well I gues it doesn't work unless you use to super huge playlist then 17.55.29 # It is not about battery runtime. It is about device run time! :-) 17.55.55 # gevaerts: not necessarily, if you shutdown at 1%, you cleany save the current config, if you shutdown at 0%, you don't 17.55.57 # I use a 500-track 22hr playlist on Repeat All. 17.56.00 # *cleany 17.56.21 # ... and still it appears it doesn't work. 17.57.07 # So, what other options do we have for determining how long a device ran before a BSoPO? 17.57.17 # I expect that with the voltage fix it will now work, because it's not crashing anymore 17.57.33 # What makes you think it is not crashing any more? 17.58.28 Quit Tristitia (Remote host closed the connection) 17.58.56 # because 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.21 # that seems to indicate it powers down simply because the batery is low 18.00.11 # now 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.04 # OK, 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.42 # I think four crashes, all around ~25h is *very* unlikely 18.02.49 # I've seen confusion! 18.03.16 Quit elensil (Quit: Leaving.) 18.03.25 # you 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.30 # I wouldn't leave something so important to debate! I'd test it :-) 18.05.34 # gevaerts: 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.53 # well stare at your device for 25h 18.06.00 # :-) 18.06.15 # and at 24h, give me the battery voltage 18.06.20 # I'd rather record the audio. 18.06.58 # But really is there no way in RB? E.g. a loging plugin. 18.07.11 # chrisjj: 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.12 # Neddless to say I don't care about battery drain. I'm not using the battery. 18.07.18 # Fast work :-) 18.08.01 # So for me, voltage fix + that explains everything except the "unit N" that has the weird dots and data abort on boot 18.08.57 # You 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.04 # Yeah, 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.13 # pamaury: 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.16 # *power from batery 18.11.24 # Gawd! Well, glad to caught it. 18.11.35 # pixelma: yeah I guess you are right 18.12.29 # still feels a bit wrong though, because I'm sure the playback code will happily read from storage at 1% 18.13.17 # actually I don't know when rockbox shutdowns, it probably doesn't wait for 0% 18.13.20 # It 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.32 # I think it depends on battery_level_shutoff 18.18.18 # actually you are right, it may shutdown at more than 0%, but batt_safe will always be false even in this case 18.34.54 # ZEN 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.43 # pamaury, 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.51 # I 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.44 # *their 18.45.28 Quit athidhep (Quit: athidhep) 18.47.27 *** Saving seen data "./dancer.seen" 18.48.06 # hmmm, I think stmp3700 will require a completely different approach to charging than imx233 18.50.43 # You 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.29 # TLDR; Until we have get proven stable execution, nowdt will save time and confusion. 18.51.48 # d/get/ 18.53.21 # Perhap 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.57 # You 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.03 # nowdt 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.29 # wodz: hey :) did you have time to try anything with audio on nwz ? 18.59.02 # pamaury: 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.32 # pamaury: Maybe I'll find some time tonight 19.00.29 # It 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.17 # Oops, 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.00 # Can 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.03 # chrisjj: 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.12 # actually writes are probably cached but open(), write(), close() most probably flushes to disk 19.38.15 # As far as I know, writes are cached up to a full sector 19.38.41 # But you can always call fflush() 19.39.05 # Hmm, maybe not 19.41.06 Quit Moarc (Ping timeout: 260 seconds) 19.41.34 # I'm not sure we have fflush() 19.41.40 # but possibly close() flushes 19.41.47 # with have storage flush 19.41.50 # close() definitely does 19.42.19 # then I guess open(), write(), close() is good enough 19.42.22 Join Moarc [0] (~chujko@a105.net128.okay.pl) 19.42.23 # We don't have a filesystem cache as such 19.42.28 # it's what batery bench does 19.42.57 # ah yeah you're right, it's per file cache for the current sector 19.44.04 # I'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.50 # well 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.31 # You can't really read one byte at a time 19.48.33 # it's the minimal amount of caching you need in a sane design 19.48.45 # you could read a sector, take one byte and through it away ;) 19.48.49 # *throw 19.48.52 # well 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 # <__builtin> afaik we don't do any I/O buffering 19.55.48 Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) 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.36 # chrisjj: 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.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.26 # pamaury: when do you think you'll have time to progress on the nwz port? 21.36.48 # this week-end 21.37.55 # great 21.38.49 # pamaury, I think I understood correctly, that writes to file end up on disk /provided/ no crash in the meanwhile. 21.39.52 # chrisjj: where meanwhile == in the next millisecond or so 21.39.56 # What I'm asking is can plug-in code get writes to file actually written to disc upon request. 21.40.13 # Oh? Millisecond? 21.40.21 # write is a write, you write to disk 21.40.42 # there is avery small amount of buffering involved but if you open(), write(), close(), it's on disk 21.40.53 # what I already explained is that this *not* what battery bench does 21.41.09 # battery bench only does open(), write(), close() on storage idle callback 21.41.54 # and 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.55 # I'm not asking about battery_bench, but about plug-in code in general. 21.43.24 # So 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.02 # plugin is no different from any other code, it uses open, write and close 21.44.15 # depends on how it's implemented 21.44.17 Join furrywolf [0] (~randyg@107.25.30.188) 21.44.31 # battery bench is one way of implementing things 21.44.33 # the right way 21.45.44 # You're saying it depends on how close() is implemented? 21.45.56 # no it depends on how the plugin is implemented 21.46.04 # Great. Thanks. 21.46.24 # there is fsync also to force a flush to disk, in case where you don't want to close the file 21.47.10 # Then 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 # <__builtin> fsync() isn't exposed in the plugin API though 21.47.27 # Got it, and thanks jhMikeS, 21.48.39 # then modify battery bench to log every minute instead of registering an idle callback 21.51.20 # Indeed 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.14 # pamaury: 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 # <__builtin> what is `ISTM' supposed to mean? 21.53.39 # __builtin: are you really reading?! 21.54.49 # "It Seems To Me" https://www.google.co.uk/search?espv=2&q=ISTM+acronym 21.54.59 # chrisjj: 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.17 # dys: cool :) 21.56.00 # <__builtin> https://www.rockbox.org/wiki/IrcGuidelines: "Use clear, grammatical, correctly-spelled English." 21.56.13 # pamaury, Does https://www.rockbox.org/tracker/task/9155 'written when the disk is active anyway' still apply? 21.57.52 # chrisjj: are you reading what we say ? 21.57.57 # Yup. 21.58.04 # Does that still apply? 21.59.33 # We just spend many lines explaining to you that battery bench only writes when the disk is active 21.59.53 # '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.01.08 # ? 22.01.19 Join edhelas [0] (~edhelas@145.133.43.230) 22.01.41 # Store being 'disk' in this case. 22.02.34 # I'm not following your logic here 22.02.36 # This 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.48 # OK, sorry to be unclear. 22.03.08 Join Senji_ [0] (~Senji@85.187.103.250) 22.03.13 # pamaury: we have strings! however, curiously, the first 400kB read ff/00. I hope it's not some lock bit preventing readout 22.04.57 # dys: 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.57 # If 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.14 # chrisjj: that's not how buffering works, at all 22.05.14 # Then your assumptions are incorrect 22.05.45 Quit michaelni (Ping timeout: 258 seconds) 22.05.46 # Write buffering, or track buffering? 22.05.47 Quit Senji (Ping timeout: 240 seconds) 22.06.22 # chrisjj: 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.38 # That's my understanding too. 22.07.02 # And since my tests are feeding 2.4Gb of tracks, the buffering must at some time load tracks in play. 22.07.17 # Strictly speaking, no 22.07.31 # Parts of tracks, yes 22.07.32 # But I recognise that if it has a very low watermark... 22.07.43 # .. (though goodness knows why on flash)... 22.07.54 # ... then disc activity is still rare. 22.08.09 # with compressed formats, you don't need to rebuffer that much 22.08.10 # Parts of tracks is fine. 22.08.12 # Yes, which is *exactly* the opposite of what you were saying 22.08.15 # Please stop trolling 22.08.45 # A 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.46 # So, is there anything on e.g. System > Debug that shows disc activity? I'll see what it is doing in these tests. 22.09.14 # Meanwhile if anyone has a better explanation for discharge succeeding and charge failing, I'd love to hear it. 22.10.05 # I'm using 5Mb tracks already compressed. 22.11.23 # How 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.18 # if you follow the logic up to the end, the watermark must be pretty low, otherwise it doesn't make sense 22.12.46 # <__builtin> lebellium: I've found that reading /some things/ is a waste of time and effort :P 22.13.53 # I'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.04 # wodz: 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.04 # but 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.04 # sconnect USB or just everything hangs? 22.14.11 # Can't I just see from Debug when the buffer is loaded? That would answer the mystery. 22.14.59 # there is some buffering debug screen somewhere I think 22.15.11 # chrisjj: it still makes sense on flash, despite what you think 22.15.22 # Yup, I've seen it mentioned in IRC but not found it. 22.15.37 # read/write require the flash and controller and clocks to be powered, you want to minimize that 22.16.29 # Sure, but flash 'spin-up' is tiny compared to disc spin-up, in power consumption terms. 22.17.18 # Is there something like itunes for rockbox? 22.17.49 # amazoniantoad: in what sense? 22.17.52 # <__builtin> amazoniantoad: not really 22.18.07 # A library manager I guess. I'd like to have a gui for managing my playlists and stuff 22.18.18 # not specifically for rockbox, but there are plenty of those sorts of programs around 22.18.34 # Will the work with rockbox? 22.18.34 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 22.18.36 # they* 22.19.10 # amazoniantoad: you get to try them and find out! 22.19.17 # scorche: did you see the current state of the forums? 22.19.26 # rockbox isnt anything special - files are files on disk, etc 22.19.39 # amazoniantoad: if you're *really* bored and motivated, it's actually not impossible to get itunes to work with rockbox 22.19.39 # gevaerts: nope 22.19.49 # scorche: some database issue now 22.19.58 # gevaerts: yes - i see that now :) 22.20.03 # thanks 22.20.07 # Well I was considering writing a program to retain my playlists while still sorting the songs to the appropriate bands/albums 22.20.16 # But I'm hoping some gui like iTunes will do that for me. 22.20.23 # chrisjj: 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.08 # Let's not mention Shuffle :-) 22.21.15 # amazoniantoad: there likely is such a thing in existance, but it isnt really the focus of this channel 22.21.19 # The 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.40 # Regardless, do you have any other idea why charging battery_bench is failing, or any guessed workaround? 22.21.48 # scorche, 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.56 # Great community here. 22.23.27 # pamaury, 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.15 # gevaerts: its back 22.24.20 # Yay! 22.24.45 # gevaerts: feel free to ping me when you notice this 22.25.03 # i am bouncing the server often enough, but often fail to actually check that it came up cleanly 22.25.25 # scorche: oh, I do, usually when you're asleep :) 22.25.51 # oh - so you did 22.26.11 # chrisjj: I'm pretty sure I did 22.26.22 # OK, nice to know. 22.28.45 # I'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.59 # pamaury, 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.44 # It doesn't wake. 22.33.41 # (Mostly.) 22.35.24 # So I wonder... Did you find out whether RB code can even detect whether the RAM is 32 or 64Gb? 22.36.13 # s/Gb/Mb/ 22.36.42 # (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.38 # rockbox can detect the size but currently it only uses the size set at compile time. Changing that is not trivial 22.42.39 # TheSeven: 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.01.00 # amazoniantoad, how did your bluetooth project work out 23.03.13 # Bilgus, not quite done. I was never able to get around to this final step. Will have time in a little bit 23.03.25 # prof_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.33 # Trying to finish up my program to rip songs from spotify. TAILS is being a bitch though. 23.03.49 # I guess it's just all locked down. 23.04.17 # Bilgus, I plan on finishing it today though. 23.04.53 # LOOKFOR saver2 by zigzag 23.05.37 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) 23.05.53 # oh nice. 23.06.16 # pamaury, OK, so RB could be inadvertently sensitive to RAM size. 23.06.20 # lets not talk about ripping songs from spotify here... 23.06.23 # Well 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.44 # scorche, oh I didn't mean spotify the music app. I meant something totally unrelated to the spotify music streaming service. 23.06.50 # Spotify is what we call my uncle joe. 23.06.56 # It's his nickname from childhood. 23.07.02 Join Exo_ [0] (45786f4c@gateway/web/freenode/ip.69.120.111.76) 23.07.05 # amazoniantoad: either way, it doesnt have anything to do with Rockbox... 23.07.12 # fan service… http://ansel.ydns.eu/~andreas/getting_serious_with_a_blackfin_port.jpg 23.07.18 # I'll make sure to tell my uncle joe. 23.07.50 # dys: I like that! 23.07.59 # Heya folks... anyone familiar with the H340 and the iflash adapters? 23.08.31 # pamaury: Could you point me to instruction how to install bootloader on nwz? 23.10.57 # anyone here with nw-zx100 ? 23.14.22 # wodz: writing instructions... 23.14.45 # pamaury: Is toolchain rework commited or it sits somewhere on gerrit? 23.17.40 # found it 23.20.16 # wodz: thanks! i will test it tomorrow and send you my findings 23.20.48 # prof_wolfff: If you want me to test something, ping me 23.22.00 # wodz: https://gist.github.com/pamaury/951cbe4e361da46a8ff9027b21381cdd 23.22.19 # wodz: it's in the NWZ commit I think 23.22.21 Quit amayer (Quit: Leaving) 23.23.13 # wodz: what is your device again ? 23.23.26 # ok, 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.36 # wodz: ^ 23.23.37 # pamaury: yeah, you should untangle rockboxdev.sh change from that and just commit. 23.23.43 # pamaury: e474 23.23.54 # prof_wolfff: ok 23.25.28 # wodz: 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.33 # yep, give me 5min to add it 23.27.32 # pamaury: I compile toolchain now so you have some time :P 23.27.37 # ok :) 23.30.35 # Build Server message: 3New build round started. Revision d4303ac, 255 builds, 15 clients. 23.31.58 Quit mutnai (Quit: Page closed) 23.32.33 # wodz: I updated gerrit 23.32.42 # great 23.33.30 # I tried to compile the bootloader for NWZ-E470 and it works, so you should not encounter any problem 23.33.43 # but 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.50 # pamaury: Please send as compiling toolchain will take a while 23.36.24 # *sigh* … H74R … The markings on tiny chips are really unforgiving (pamaury) 23.37.17 # If anyone has an idea what this critter could be, I'd be highly interested 23.37.36 # (8-pin case, suspected flash) 23.37.55 # wodz: https://www.dropbox.com/s/f49huqibakz9uju/NW_WM_FW_nwze470.UPG?dl=0 23.38.45 # dys: 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.07 # pamaury: can the blackfin boot from i2c, too? 23.39.28 # not sure, I'm checking 23.41.08 # ok. 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.17 # pamaury: http://paste.debian.net/911017 :-/ 23.41.24 # dys: apparently not, it supports uart, link port, emmc, sd and spi 23.42.01 # wodz: install libmpfr-dev, libgmp-dev and libmpc-dev 23.42.07 # Build Server message: 3Build round completed after 691 seconds. 23.42.08 # Build Server message: 3Revision d4303ac result: All green 23.42.14 # There was a site to decode smd part *markings* but can't remember the url 23.44.20 # can I assume the first megabyte of the card will contain all relevant info to debugging this? 23.46.21 # furrywolf: mbr + partition table is fraction of this 23.46.42 # +fat, since someone was suspecting filesystem oddness 23.51.44 # ok, 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.40 # pamaury: Any special way to write scripts run from 'debug tools' menu? 23.53.05 # ... 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.19 # cfdisk is saying it's fat32, fdisk says it's ntfs. 23.53.41 # I'm guessing it's set to something funky, and rockbox is ignoring it. 23.54.06 # furrywolf: What capacity is this card? 23.54.49 # yep, that was it. 23.55.09 # wodz: no, just make sure they work with sh, and not bash 23.55.36 # 128gb, 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.48 # pamaury: Does it need to be decorated with #!/bin/sh or something? 23.56.02 # changing the partition type to 0b makes rockbox read it. 23.56.29 # furrywolf: partition type and filesystem are two different things 23.56.43 # wodz: no, I run it with "sh