--- Log for 16.01.117 Server: nylund.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 11 days and 3 hours ago 00.02.50 # pamaury: I boot to original apple firmware and then connect the device to PC - so I always have to power down and up after an upload 00.03.12 # massa: ok 00.05.22 # massa: I think I found the problem 00.05.48 # pamaury: the crash is persistent - I uploaded the zip here: http://www.mohrenclan.de/rockbox/ipodvideo_with_g%231499_2017-01-15_23-58.zip 00.06.06 # (map and so on is included) 00.08.39 # massa: can you changes those this line: in apps/gui/skin_engine/skin_parser.c: 00.08.49 # change skin_buffer = ALIGN_UP(skin_buffer, 2); /* align on 4-byte boundary */ 00.08.49 # into skin_buffer = ALIGN_UP(skin_buffer, 4); /* align on 4-byte boundary */ 00.08.55 # (ie 2 becomes 4) 00.09.10 # massa: what is the backtrace you see ? 00.10.12 Join shmibs [0] (~shmibs@shmibbles.me) 00.11.47 # pamaury: http://www.mohrenclan.de/rockbox/Rockbox_ipodvideo_crash.jpg 00.16.19 # yeah that sounds about right 00.16.28 # can you try with the change I suggested in skin_parser.c ? 00.16.44 # it's building 00.19.47 # <[Saint]> ParkerR: Our threading model pisses off the Android Run Time as it doesn't like external calls. There's an almighty great hack up on gerrit that pushes what it's bitching about into the button queue, but it makes the user experience less than desirable. 00.21.49 # <[Saint]> The Dalvik Run Time was much more forgiving in this regard. Google has been on a slow march to making using the Native Development Kit unreasonably annoying for years. 00.21.59 # pamaury: with the change it works again :-) 00.23.34 # [Saint], Ahh 00.24.46 # [Saint], I think I figured out why the choice of tables was made for the time values that have a large range.. Memory, the whole list gets loaded at once, I suppose this is for list acceleration to work properly 00.25.53 # massa: great 00.25.57 # I upaded the gerrit task 00.26.14 # I find that strange for contiguous integer values though 00.26.31 Quit xorly (Ping timeout: 260 seconds) 00.29.22 # massa: thanks for your time 00.29.25 # going to bed now :) 00.29.37 # * massa likes what pamaury did today :-) 00.30.12 # I'm also going to bed now - have to work tomorrow - actually today ;-) 00.30.24 # Bye everybody! 00.30.35 # <__builtin> bye! 00.30.39 Quit massa () 00.34.05 # __builtin So what has to happen for this change to reach the master? 00.35.42 # <__builtin> well, after it's been +2'd you need to submit it 00.37.51 Join Strife1989 [0] (~quassel@adsl-98-67-59-222.mcn.bellsouth.net) 00.40.55 # massa: All four of you sim binaries run here (Win 7 Pro 64-bit) inc. play audio etc. 00.41.09 # OOI, what's your purpose with the 64-bit variants? 00.41.28 Quit Strife89 (Ping timeout: 240 seconds) 00.41.31 *** Saving seen data "./dancer.seen" 00.42.13 Quit pamaury (Remote host closed the connection) 00.43.22 Join smoke_fumus [0] (~smoke_fum@dynamic-vpdn-93-125-15-142.telecom.by) 00.48.28 Quit ender` (Quit: A man should live forever or die trying. — Spider Robinson) 00.49.00 Quit girafe (Read error: Connection reset by peer) 00.58.04 Quit Galois (Ping timeout: 252 seconds) 00.59.23 # <[Saint]> Perhaps even more annoyingly, the 'almighty great hack' to push threading into the button queue only works on Android between 5.0 and 6.1.1 00.59.55 # <[Saint]> 7.0+ adds further levels of craziness for anyone unfortunate enough to dare use native code in their application. 01.01.47 # <[Saint]> chrisjj: I....what? 01.01.47 # <[Saint]> I know damn well I'm going to regret asking this, but what on Earth do you mean regarding a "purpose" for 64bit native binaries? 02.23.19 Quit Senji (Ping timeout: 252 seconds) 02.26.16 Quit ZincAlloy (Quit: Leaving.) 02.41.33 *** Saving seen data "./dancer.seen" 02.43.28 Quit prof_wolfff (Ping timeout: 240 seconds) 02.56.21 Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) 03.05.36 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 03.22.12 Join zoid [0] (~zoid@unaffiliated/taxationistheft) 03.22.40 # Does Rockbox support video playback? 03.29.58 Quit snow_bckspc (Quit: User was destroyed by a weapon of mass destruction.) 03.30.45 Join snow_bckspc [0] (~snow_bcks@ganon.dot-server.net) 03.47.01 Join clockwork [0] (461dac7c@gateway/web/freenode/ip.70.29.172.124) 03.47.35 Quit clockwork (Client Quit) 04.07.19 Join Strife89 [0] (~quassel@adsl-98-80-191-141.mcn.bellsouth.net) 04.08.10 Quit Strife1989 (Ping timeout: 240 seconds) 04.10.35 Quit idonob_ (Ping timeout: 240 seconds) 04.16.30 # for certain definitions of the word "video" 04.16.49 # https://www.rockbox.org/wiki/PluginMpegplayer 04.17.24 # zoid, 04.40.16 Quit mc2739 (Ping timeout: 260 seconds) 04.41.35 *** Saving seen data "./dancer.seen" 05.15.08 Join _mt__ [0] (~MT@2601:482:4402:7b60:f44b:bcda:8e41:edd5) 05.16.27 Quit _mt_ (Ping timeout: 256 seconds) 05.22.41 Quit _mt__ (Ping timeout: 256 seconds) 05.29.07 Join _mt_ [0] (~MT@2601:482:4402:7b60:8025:71f8:9d38:6cf7) 05.41.41 Join alyssa [0] (~alyssa@unaffiliated/alyssa) 05.42.16 Part alyssa 06.06.53 Quit _mt_ (Ping timeout: 256 seconds) 06.08.35 Quit bray90820 (Ping timeout: 256 seconds) 06.14.14 # Thanks soap 06.15.58 Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com) 06.23.41 Quit TheSeven (Ping timeout: 258 seconds) 06.24.02 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.41.39 *** Saving seen data "./dancer.seen" 07.05.43 Join idonob_ [0] (~Owner@50.67.32.65) 07.32.51 Join parchd [0] (~parchd@unaffiliated/parchd) 07.43.39 # morning 07.54.16 # soap: how cool 08.01.31 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 08.01.31 Quit pixelma (Quit: .) 08.01.42 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 08.01.45 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 08.15.38 Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) 08.25.40 Join ender` [0] (krneki@foo.eternallybored.org) 08.41.40 *** Saving seen data "./dancer.seen" 09.13.58 Join petur [0] (~petur@91.183.48.77) 09.13.58 Quit petur (Changing host) 09.13.58 Join petur [0] (~petur@rockbox/developer/petur) 09.14.26 Quit xorly (Ping timeout: 260 seconds) 09.39.29 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 09.44.17 Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) 09.52.34 Quit idonob_ (Ping timeout: 240 seconds) 09.54.58 Join idonob_ [0] (~Owner@50.67.32.65) 09.55.15 Quit xorly (Ping timeout: 240 seconds) 10.02.13 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 10.09.28 Join elensil [0] (~edhelas@2001:1c02:1903:d800:f130:e0b0:3ab9:cebf) 10.15.00 Join Senji [0] (~Senji@85.187.103.250) 10.16.13 Quit pamaury (Ping timeout: 256 seconds) 10.19.47 Quit krnlyng (Ping timeout: 258 seconds) 10.21.42 # bah 10.21.52 # Guess which commit broke checkwps 10.22.50 # jhMikeS: can you have a look at checkwps? It's apparently been broken since "rework filesystem" 10.22.54 Quit MrZeus (Read error: Connection reset by peer) 10.31.23 Join MrZeus [0] (~MrZeus@81.144.218.162) 10.32.58 Join krnlyng [0] (~liar@77.117.40.122.wireless.dyn.drei.com) 10.41.43 *** Saving seen data "./dancer.seen" 10.48.07 Quit petur (Read error: Connection reset by peer) 10.48.17 Quit paulk-blaze (Remote host closed the connection) 10.48.18 Join petur [0] (~petur@91.183.48.77) 10.48.18 Quit petur (Changing host) 10.48.18 Join petur [0] (~petur@rockbox/developer/petur) 10.50.18 Join MrZeus_ [0] (~MrZeus@81.144.218.162) 10.53.40 Quit MrZeus (Ping timeout: 240 seconds) 10.54.06 # gevaerts: sure 10.54.10 Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) 10.55.00 # gevaerts: what's happening? 10.59.11 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 11.00.21 Join xorly [0] (~xorly@193.85.203.185) 11.00.25 Quit elensil (Ping timeout: 256 seconds) 11.02.38 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 11.05.17 Quit xorly (Ping timeout: 252 seconds) 11.06.14 Join xorly [0] (~xorly@193.85.203.185) 11.09.28 # jhMikeS: looks like open_utf8() in skin_parser.c:2468 is failing, returning -3 11.10.07 Quit petur (Read error: Connection reset by peer) 11.12.30 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.12.53 # * gevaerts looks at sim_open() 11.12.56 # gevaerts: is it supposed to run with a simulated tree or as completely native 11.13.03 Join elensil [0] (~edhelas@2001:1c02:1903:d800:f130:e0b0:3ab9:cebf) 11.13.19 # open could be hooked to the wrong stuff 11.14.10 Quit Bray90820 (Ping timeout: 240 seconds) 11.14.14 # simulated, I think 11.14.20 Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com) 11.15.34 # OK, so what's going on is that ospath in sim_open() is now suddenly relative 11.16.22 Quit bzed (Ping timeout: 256 seconds) 11.17.12 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 11.17.58 Join petur [0] (~petur@91.183.48.77) 11.17.58 Quit petur (Changing host) 11.17.58 Join petur [0] (~petur@rockbox/developer/petur) 11.18.41 # As in, I pass /tmp/wavy/wps/wavy.wps to checkwps, and it ends up looking for ./tmp/wavy/wps/wavy.wps 11.18.42 # hmmm, I see a '.' being prepended 11.19.05 # there's probably a reason, like no base dir being provided 11.19.26 # sim_root_dir 11.20.29 # That one probably should be / instead of . I guess 11.20.57 # Or would that break relative paths? 11.21.00 # * gevaerts tries 11.21.52 # just ""? 11.22.36 Quit pamaury_ (Ping timeout: 248 seconds) 11.22.37 # or "" work 11.22.46 # "" will just prepend nothing 11.23.16 # "/" or "" work for absolute paths, neither work for relative. I don't actually know if relative has ever worked there in that way though 11.23.17 Quit petur (Read error: Connection reset by peer) 11.23.43 Join petur [0] (~petur@rockbox/developer/petur) 11.24.48 # Right, sim_get_os_path doesn't do relative paths at all 11.26.47 # * gevaerts tries to figure out if the themesite uses absolute paths 11.29.12 # normally it simulates in the simdisk directory and so rejects them 11.29.45 # and relative bits that would take you above the sim root would be clipped 11.30.09 # * gevaerts nods 11.30.47 # not even sure why it builds that file for an external utility anyway 11.31.14 # Looks like things work fine for checkwps if I comment out the absolute path check 11.31.30 # Maybe add an #ifndef __PCTOOL__ around that? 11.31.30 Quit TorC (Read error: Connection reset by peer) 11.31.44 # The database tool presumably will have similar issues 11.33.11 Join TorC [0] (~TorC@fsf/member/TorC) 11.36.15 Quit Senji (Ping timeout: 240 seconds) 11.37.19 # jhMikeS: http://paste.debian.net/908951/ makes things work for me. Not sure if that's a clean enough fix, and I have no idea if the database tool was broken or gets fixed (I don't actually know how it works...) 11.37.59 # I'm not sure if I want to get into bypassing sim_*() for checkwps and database though, IIRC that set of macros is poisonous and bites if you don't spend a week on them 11.38.54 # which? 11.39.23 # you mean the ones that map regular posix calls to sim_*? 11.39.48 # Yes 11.40.26 # I have vague but not very nice memories of those from when the app builds were added 11.40.35 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:9812:c041:b256:ada3) 11.40.39 # I'm pretty sure I spent well over a week on them. It was completely redone 11.41.12 # Ah, then you know what they were like :) 11.41.38 # indeed 11.41.46 Quit petur (Read error: Connection reset by peer) 11.41.49 # * jhMikeS has seen some shit 11.42.13 Join petur [0] (~petur@91.183.48.77) 11.42.13 Quit petur (Changing host) 11.42.13 Join petur [0] (~petur@rockbox/developer/petur) 11.42.43 # If you can make __PCTOOL__ (i.e. database and checkwps) easily use straight open(), go for it. Otherwise, I think just disabling that path_is_absolute() check for them is probably find 11.42.47 # *fine 11.42.50 # I'm trying to discern the true intent of using sim api functions 11.43.35 # since really it only enforces native target-like behavior to parsing a path 11.45.47 # then again, maybe you want that if parsing is supposed to be in the context of running on a target 11.48.14 # you're supposed to run the tool with the cwd being "root"? 11.48.28 # Hmmm, database probably still needs a sim_root_dir of ".". It's supposed to be run from the target directory 11.49.03 # checkwps on the other hand can (or could) be run from anywhere 11.49.30 # So for database the current behaviour is probably correct 11.49.33 # it sounds like it shouldn't be using sim_ functions at all 11.51.10 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 11.56.31 Join Senji [0] (~Senji@85.187.103.250) 12.00.22 # maybe it should be an app build instead of a sim? 12.02.08 Quit Senji (Ping timeout: 258 seconds) 12.04.40 # checkwps as an app build does indeed work 12.05.24 # But again, not sure about database. I *think* that one needs to have the sim's concept of a root directory 12.05.40 # Which means we have to split up __PCTOOL_ for those 12.08.55 Join bzed [0] (~bzed@shell.bzed.at) 12.13.21 Quit ZincAlloy (Quit: Leaving.) 12.14.42 # why? 12.15.17 # I don't know for sure :) 12.16.01 # I mean, I'm assuming that the database stores pathnames, and those pathnames have to be absolute within the context of the rockbox root 12.16.26 # I don't know if they will be correct if the sim logic isn't used 12.16.41 # true 12.16.52 # Anyway, assuming the database has to remain on sim logic, http://paste.debian.net/908960/ seems to fix things for me 12.16.57 # It would be logical that the database stores absolute name and wps store relative names. 12.17.25 # that moves checkwps to app logic and leaves database on sim logic 12.17.52 # (and re-adds win32 support for both, which is of course untested) 12.19.31 # I'm still trying to figure out how the old checkwps got its sim root 12.20.38 # By accident, probably :) 12.20.59 # Did it actually use the sim_*() functions? 12.21.04 # is APPLICATION defined when building those? 12.21.51 # It isn't *now* 12.22.08 Quit paulk-blaze (Quit: Leaving) 12.22.27 # wait, so they used to define APPLICATION 12.22.28 # ? 12.23.10 # No idea :) 12.23.37 # I know it's not defined now, but I didn't check the old code 12.26.53 # no need for sim_root_dir would explain it because it just defined as a noop 12.27.03 # was defined 12.41.45 *** Saving seen data "./dancer.seen" 12.46.27 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 12.48.37 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 12.50.55 # gevaerts: Previously, CheckWPS didn't include sim file code at all 12.51.24 # it actually shouldn't be there 12.53.44 # and the database tool doesn't seem to even compile becauase of some multivolume junk 12.54.43 # * jhMikeS is of course refers to a checkout of the revision just before big FS code change 12.57.10 # sim_* was SIMULATOR || DBTOOL 13.02.01 Join skapazzo [0] (~skapazzo@151.9.205.1) 13.11.43 # gevaerts: who does the honors? you did the patch and I think it's right 13.14.29 # jhMikeS: go ahead. I'm a bit busy... 13.18.12 # np 13.31.39 # Build Server message: 3New build round started. Revision 4f7fea2, 255 builds, 13 clients. 14.02.42 Quit xorly (Ping timeout: 245 seconds) 14.27.36 # jhMikeS: looks like the themesite can properly check themes again! (and then promptly die, but I claim that that's not checkwps' fault) 14.31.29 Quit TorC (Read error: Connection reset by peer) 14.33.12 Join xorly [0] (~xorly@193.85.203.185) 14.34.02 Join TorC [0] (~TorC@fsf/member/TorC) 14.40.46 # haha 14.41.48 *** Saving seen data "./dancer.seen" 14.56.27 # Chrisjj 15.01.37 # * chrisjj sees http://themes.rockbox.org/ This site can’t be reached themes.rockbox.org took too long to respond. 15.02.24 # Which is no real surprise since forums. and themes have gone down just about every day for the last month. 15.02.49 # What exactly is the DoS attack that's been blames for this? 15.03.23 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:c9df:62a2:1d87:d501) 15.04.07 # And who would want to attack rockbox.org anyway? 15.06.31 # There is no DoS attack 15.17.34 Quit wodz (Quit: Ex-Chat) 15.17.54 # but but but oh yeah https://www.rockbox.org/irc/log-20161219#04:30:27 15.24.04 # OK, so people variously are saying it is DoS, and it is not a D-DoS, and it is not an attack, and it is triggering an Apache bug, and it might get fixed in a month or so. 15.24.44 # * chrisjj hopes forum users are sufficiently patient. 15.32.37 Quit petur (Read error: Connection reset by peer) 15.47.39 # scorche: what is the apache bug ? It is because of an old apache installation or bad config ? 15.48.34 # pamaury: at this point I somehow doubt it's an apache issue 15.49.29 # What I've seen the last few days is that if I run a script (over an ssh login) that produces a large amount of output, the server dies 15.49.59 # dies as in ? reboots ? freeze ? 15.50.24 # My connection freezes and new connections time out 15.50.50 # What, no watchdog to reset the server?? :-) 15.52.09 # gevaerts: that sounds like a hardware problem potentially 15.53.23 # Or possibly a bad network driver, but yes, given that it used to work fine and that there has not been a major OS upgrade, hardware is not unlikely 15.53.27 Join petur [0] (~petur@91.183.48.77) 15.53.27 Quit petur (Changing host) 15.53.27 Join petur [0] (~petur@rockbox/developer/petur) 15.55.10 # would a migration be complicated ? I don't mind hosting it if it helps. Because the forums are down a lot these days 15.56.12 # Not sure if that's needed. I believe scorche also uses the server for other things, so if it's hardware he presumably also would like to see it fixed 15.59.19 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 16.00.10 # I have a theory on why memDFS battery_bench.txt (ZEN charging an empty battery) only ever gets one entry. The watchdog is rebooting the device after the first one, leaving the device with screen looking exactly the same, but with the BB plugin stopped. 16.04.04 # chrisjj: did you benchmark lcd sleep vs no lcd sleep ? 16.05.14 # No. I'm still trying trying to benchmark memDFS. And failing due to BSoPO. 16.06.10 # If your lcd* are on the same base, I think the same problem will prevent me benchmarking them too. 16.06.22 # <__builtin> chrisjj: what the heck is a "BSoPO"? 16.06.40 # Black Screen of Power Off. 16.07.32 # ZEN builds since Dec are mysteriously spontaneously going to power-off state after anything from 3min to 3hr after clean boot. 16.08.02 # Depends on some variables, but I haven't pinpointed them 16.08.38 # chrisjj: instead of benchmarking memdfs, then it would be better to find the offending commit don't you think ? 16.08.57 # Be my guest! :-) 16.09.01 # Or tell me how to. 16.10.09 # what is the last know working commit again ? 16.10.12 # *known 16.10.14 # Re my theory at [15:00], I have no idea what's angering the watchdog. Not memDFS it seems - the same issue shows on non-memDFS build be68b6a7b-170109. And though most BSoPO have appeared in playback, there's no playback in the case. Device is doing nothing but charging. 16.11.42 # The last known (to me) /build/ free from BSoPO is lcd_fix - 45697a0bf-161212. 16.12.41 # And yes I agree, finding the offender should be the priority. 16.14.43 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 16.17.12 # * chrisjj testing IRC after wrinkle 16.17.28 # * chrisjj wonders how many pamaury clones exist. 16.18.52 # chrisjj: ok, so we are clear: I will send you builds with modified source, where the modification is g#1503 (disable watchdog) so you can't complain about watchdog 16.18.53 # 3Gerrit review #1503 at http://gerrit.rockbox.org/r/1503 : 3imx233: disable watchdog for debugging (DON'T PUSH) by Amaury Pouly 16.20.15 # Thanks. 16.20.18 # Feature suggestion: Setting to disable reset on watchdog. 16.20.47 # 'Cos I know I am not the only one who will want this for ZEN testing. 16.22.12 # * pamaury_ notes that g#1503 is untested and does not promise in any possible way that this could achieve what he claims 16.22.13 # 3Gerrit review #1503 at http://gerrit.rockbox.org/r/1503 : 3imx233: disable watchdog for debugging (DON'T PUSH) by Amaury Pouly 16.23.36 # chrisjj: please test https://www.dropbox.com/s/6rhrcf7z430vsjn/rockbox_zen_cd8b33327_nowdt.zip?dl=0 16.24.53 Join amayer [0] (~amayer@mail.weberadvertising.com) 16.29.51 # OK, but to save me time adding a another device to the set, first could you help me confirm my theory of [15:00]? 16.31.10 # I.e. how can I determine whether a default-settings ZEN on charge on PC in non-USB-mode is getting watchdog reboots? 16.31.40 # Not that default settings means backlight slept. 16.31.41 # I can send you a build with HEAD + no watchdog if that helps 16.31.51 # if that's what you want 16.32.38 # Perhaps the answer is: You would see the BL text for sure. (I don't know, since I know no way to test by manually angering the watchdog in this state.) 16.33.57 # Thanks, but if there's an answer I can apply without changing any of the current four test devices, it would be good. 16.34.53 # s/Thanks, but/Thanks for that build offer, but/ 16.35.38 # chrisjj: what about starting the device, plug usb with a holding a key so that you get charging but still rockbox. If the watchdog triggers, device reboots into bootloader usb mode 16.36.19 # Ah, I should have thought of that. Thanks.Trying... 16.37.08 Quit paulk-collins (Quit: Leaving) 16.40.25 Quit pamaury_ (Ping timeout: 256 seconds) 16.41.49 *** Saving seen data "./dancer.seen" 16.57.41 # pamaury: I verified it using button reset to simulate watchdog reset). I.e. With Shortcut button held, connect to PC, wait for RB main menu. Press reset. Verify bootloader text appears and remains. 16.58.41 # of course 16.58.57 # * chrisjj is leaving nothing to chance. 16.59.22 # I verified it using a playback that normally triggers a BSoPO. I.e. With Shortcut button held, connect to PC, wait for RB main menu, set a WMA playing. Wait for Verify bootloader text to appear and remain. Success. 17.00.19 # (I think that also confirms somewhat that BSoPO is reset on watchdog. On internal power, it goes to power-off. On external power, it reboots.) 17.01.37 # I tried this test on the [15:00] theory re charging... but got no BL. i.e. no watchdog reset. BUT this differs from the original instances in that the charge level is high. 17.02.01 # I shall empty a battery and retry. 17.03.03 # The comment the other day that firmware upgraders often require full charge got me thinking. 17.03.05 # it could also be a hard crash of the hardware 17.03.41 # a VDDD or other power rail brownout can do that 17.04.12 # Any known way that this watchdog angering could occur at low charge and not high? 17.05.09 # E.g. on a switch from the OF charger to the RB BL charger, or RB app charger? 17.05.28 # chrisjj: I am not sure I see the point of obsessing on memdfs since obviously there is a problem and we don't even know if it is caused by mem dfs or something else 17.05.51 # I'm not obsessing on memDFS. This BSoPO is all over recent builds. 17.05.54 # removing mem dfs from the equation can only make it simpler 17.06.10 # I have done. Problem remained. 17.06.27 # I sent you a build with no watchdog, did you test it ? 17.06.44 # Not yet. As I said, I'm trying to conserve devices. 17.07.27 # I have only six free for RB testing and am about to send you two. 17.09.16 # I don't understand what you are trying to do by testing a build that we know fail 17.11.16 # I'm trying to find the conditions under which evasive fail can be reproduced, so that I/someone can do the bisect you suggested, to locate the culprit change. 17.12.06 # If you know a better way, do say. 17.12.07 # I still don't understand: strart the device, play a huge playlist, check in 6 hours if the device is still running 17.13.27 # and check battery_bench and/or the running time in the system menu 17.13.46 # (since on reset, battery bench will not restart and the running time will be cleared) 17.14.22 # That's proven insufficient. E.g. I had that test fail, then pass under possibly changed conditions, then fail on a builds from you differing in (probably only) an LCD fix. 17.15.35 # then what do you suggest ? Unless you have a 100 reliable way of triggering the bug, that's called real life debugging I'm afraid 17.15.42 # * 100% 17.16.04 # I had avoided battery bench since that looks like a (possibly the) condition causing the BSoOD, but I am near to eliminating that possibility so can hopefully return to it. 17.16.28 # Are you sure running time is reliably cleared by watchdog reset? 17.17.48 # unless I'm mistaken it's the running time since the device booted (ie not the cumulative runtime) so yes, it starts at 0 when rockbox loads and starts counting, it's not a hardware thing 17.18.06 # but otherwise by playback wouldn't be enough ? 17.18.20 # FWIW (not much) the manual does not accord and IIRC (while forums down) I've seen comment saying Running Time does not work as expected. 17.18.35 # if the device resets, playback is not restarted 17.18.55 # thus: playback => no reset, no playback => reset/crash 17.19.12 # Sorry, our [16:18]'s crossed and my [16:18] was about Running Time, not playback. 17.19.36 # I'm saying that I don't understand why you don't simply use playback 17.19.51 # that's clearly the best way to determine if a crashed happened imo 17.20.29 # * chrisjj powers-on ZEN, immediately reads Running Time, sees 14m 17.20.52 # * chrisjj powers-on second ZEN, immediately reads Running Time, sees 1h19m 17.20.55 # then maybe it's the cumulative running time 17.21.12 # I believe (not sure!) it should be the time since it was last charged 17.21.28 # ah that would make sense 17.21.58 # IIRC it's stored in nvram, which is simulated on most targets, which means it might not be updated if the device crashes 17.22.02 # manual says: 17.22.05 # Running Time: 17.22.05 # This item shows the cumulative overall runtime of your player since you either disconnected it from charging (in Rockbox) or manually reset this item. A manual reset is done through pressing any button, followed by pressing Select or Right. 17.22.13 # * chrisjj sees Top Time 1h18m, clear Top Top, resets unit, power-on, sees Top Time 1h18m. 17.22.41 # * chrisjj remains unimpressed by Running Time and Top Time, but will try power-down not reset. 17.23.21 # * gevaerts remains unimpressed by lots of things 17.23.44 # * chrisjj sees Top Time 1h18m, clears Top Top, powers-off, power-on, sees Top Time 1h18m. 17.26.25 # * chrisjj clears Running Time, clears Top Time, returns to main menu, powers-off, powers-on and sees Running Time and Top Time at 0h 0m Xs. Phew. 17.28.23 # pamaury, Top Top is not updated if the device resets, so I'm guess yes you're right in suggesting it does not update in the device crashes. 17.28.28 # * pamaury thinks chrisjj hasn't answered the question of why playback isn't a reliable way of knowing if the devivce crashed 17.28.33 # s/Top Top/Top Time/ 17.29.28 # * chrisjj assumes he wasn't sufficiently clear that the device can crash even when not playing. 17.30.15 # However, we can see how far we get with playback. 17.32.25 # if the device can crash when no playing then it crash when playing 17.32.36 # *it can crash when playing 17.33.34 # I can't see how playing music makes it more likely to not trigger the bug, quite the opposite in fact 17.34.22 Quit petur (Quit: Connection reset by beer) 17.35.38 # I'll test more. 17.35.48 # me goes AFK. 17.39.38 # well, if Running Time is currently that (1h18m) then if you reset Top Time it'll be set to current Running Time, that's to be expected 17.47.42 Join Senji [0] (~Senji@85.187.103.250) 18.00.11 Quit pamaury (Remote host closed the connection) 18.17.51 Join Guest38272 [0] (2e7df91b@gateway/web/freenode/ip.46.125.249.27) 18.41.51 *** Saving seen data "./dancer.seen" 18.46.27 Quit xorly (Ping timeout: 240 seconds) 18.48.56 Join duo8 [0] (~ZNC-SRV-H@116.96.90.249) 18.51.39 Quit cc___ (Quit: WeeChat 1.6) 18.55.58 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 18.59.05 Join petur [0] (~petur@rockbox/developer/petur) 19.08.09 Quit parchd (Ping timeout: 240 seconds) 19.09.38 Part Guest38272 19.15.45 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 19.17.48 Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr) 19.19.56 # gevaerts: thanks for the theme site 19.20.21 # Oh, it's back up? 19.20.39 Quit JdGordon (Ping timeout: 240 seconds) 19.20.48 # yep 19.21.54 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 19.25.08 # The good thing is that I don't have to touch it anymore, so it might not die :) 19.26.05 # that's a good fix 19.27.12 # <__builtin> has anyone seen http://images.agptek.us/image/RockerUserManual.pdf yet? 19.28.29 # <__builtin> it doesn't look like it's running rockbox 19.28.59 # it was unclear if it should at release time 19.30.54 # I assume the question is: does it have the sufficient SoC for a future port 19.32.09 # "Gapless Playback: Set On/Off" I never understood why you'd like to set off gapless 19.38.39 Quit jhMikeS (Ping timeout: 240 seconds) 20.01.07 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 20.04.54 # is the build server dead ? 20.05.10 # ah not it's just the bot 20.06.32 Quit cc___ (Quit: WeeChat 1.6) 20.07.09 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 20.08.49 Quit munch (Changing host) 20.08.49 Join munch [0] (pls@unaffiliated/munch) 20.08.49 Quit munch (Changing host) 20.08.49 Join munch [0] (pls@gateway/shell/elitebnc/x-hjjqdjfndwontqqf) 20.12.21 # * pamaury is on a commit spree 20.13.49 # it will probably be hard to break your own record :) 20.13.59 # <__builtin> we should probably stage a Turing test just to make sure pamaury's human :P 20.28.50 # [Saint]: I know you care about settings, would you mind telling me what you think about g#1486 ? 20.28.52 # 3Gerrit review #1486 at http://gerrit.rockbox.org/r/1486 : 3Implement speaker enable/disable on jack (un)plug by Amaury Pouly 20.30.57 Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) 20.41.55 *** Saving seen data "./dancer.seen" 21.10.39 # <__builtin> petur: your build client seems to be acting up, could you take a look? http://build.rockbox.org/shownewlog.cgi?rev=2bc5173;type=samsungyh820sim 21.10.42 # <__builtin> whois petur 21.11.29 Join ungali [0] (ungali@162-202-67-158.lightspeed.livnmi.sbcglobal.net) 21.11.29 Quit ungali (Changing host) 21.11.29 Join ungali [0] (ungali@unaffiliated/ungali) 21.24.52 Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) 21.31.40 Quit ungali (Remote host closed the connection) 21.37.25 Join TheLemonMan [0] (~root@irssi/staff/TheLemonMan) 21.58.57 Quit tchan (Ping timeout: 240 seconds) 22.11.22 # __builtin: I don't understand what's going on, I can do that sim build manually 22.31.23 Quit skapazzo (Quit: leaving) 22.31.33 Quit petur (Quit: Leaving) 22.41.57 *** Saving seen data "./dancer.seen" 22.45.33 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) 22.46.24 Quit idonob_ (Ping timeout: 260 seconds) 22.47.59 Join idonob_ [0] (~Owner@50.67.32.65) 23.08.22 # pixelma, You'd think so, wouldn't you? Until you actually try it and find that resetting Top Time sets it's display to 0h0m0s, not Running Time. 23.09.32 # And on ZEN doesn't itself set the variable at all. If the device crashes and gets reset by watchdog, or you power-off, your change is lost. 23.11.31 # Workaround: after resetting Top Time, press Back twice. Once is insufficient. 23.16.19 # if you reset the top time, it will get reset to 0 but set to running time on the next update, which is basically as soon as you leave the system menu apparently 23.16.35 # of course on reset you loose everything, which is not very surprising 23.25.52 Part robertd1 23.35.57 # chrisjj: according to your description that happened after you also reset current Running Time as suspected 23.36.05 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 23.49.06 Quit Senji (Ping timeout: 255 seconds) 23.51.39 Quit pamaury (Ping timeout: 256 seconds)