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

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

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

#rockbox log for 2017-01-16

00:02:50massapamaury: 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:12pamaurymassa: ok
00:05:22pamaurymassa: I think I found the problem
00:05:48massapamaury: the crash is persistent - I uploaded the zip here:
00:06:06massa(map and so on is included)
00:08:39pamaurymassa: can you changes those this line: in apps/gui/skin_engine/skin_parser.c:
00:08:49pamaurychange skin_buffer = ALIGN_UP(skin_buffer, 2); /* align on 4-byte boundary */
00:08:49pamauryinto skin_buffer = ALIGN_UP(skin_buffer, 4); /* align on 4-byte boundary */
00:08:55pamaury(ie 2 becomes 4)
00:09:10pamaurymassa: what is the backtrace you see ?
00:10:12 Join shmibs [0] (
00:16:19pamauryyeah that sounds about right
00:16:28pamaurycan you try with the change I suggested in skin_parser.c ?
00:16:44massait'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:59massapamaury: with the change it works again :-)
00:23:34ParkerR[Saint], Ahh
00:24:46Bilgus[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:53pamaurymassa: great
00:25:57pamauryI upaded the gerrit task
00:26:14BilgusI find that strange for contiguous integer values though
00:26:31 Quit xorly (Ping timeout: 260 seconds)
00:29:22pamaurymassa: thanks for your time
00:29:25pamaurygoing to bed now :)
00:29:37*massa likes what pamaury did today :-)
00:30:12massaI'm also going to bed now - have to work tomorrow - actually today ;-)
00:30:24massaBye everybody!
00:30:39 Quit massa ()
00:34:05chrisjj__builtin So what has to happen for this change to reach the master?
00:35:42__builtinwell, after it's been +2'd you need to submit it
00:37:51 Join Strife1989 [0] (
00:40:55chrisjjmassa: All four of you sim binaries run here (Win 7 Pro 64-bit) inc. play audio etc.
00:41:09chrisjjOOI, 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] (
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] (
03:05:36 Join Galois [0] (
03:22:12 Join zoid [0] (~zoid@unaffiliated/taxationistheft)
03:22:40zoidDoes 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] (
03:47:01 Join clockwork [0] (461dac7c@gateway/web/freenode/ip.
03:47:35 Quit clockwork (Client Quit)
04:07:19 Join Strife89 [0] (
04:08:10 Quit Strife1989 (Ping timeout: 240 seconds)
04:10:35 Quit idonob_ (Ping timeout: 240 seconds)
04:16:30soapfor certain definitions of the word "video"
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:14zoidThanks soap
06:15:58 Join Bray90820 [0] (
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@
07:32:51 Join parchd [0] (~parchd@unaffiliated/parchd)
07:54:16comradekingusoap: how cool
08:01:31 Quit amiconn (Quit: - 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] (
08:25:40 Join ender` [0] (
08:41:40***Saving seen data "./dancer.seen"
09:13:58 Join petur [0] (~petur@
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] (
09:52:34 Quit idonob_ (Ping timeout: 240 seconds)
09:54:58 Join idonob_ [0] (~Owner@
09:55:15 Quit xorly (Ping timeout: 240 seconds)
10:02:13 Join paulk-blaze [0] (
10:09:28 Join elensil [0] (~edhelas@2001:1c02:1903:d800:f130:e0b0:3ab9:cebf)
10:15:00 Join Senji [0] (~Senji@
10:16:13 Quit pamaury (Ping timeout: 256 seconds)
10:19:47 Quit krnlyng (Ping timeout: 258 seconds)
10:21:52gevaertsGuess which commit broke checkwps
10:22:50gevaertsjhMikeS: 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@
10:32:58 Join krnlyng [0] (
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@
10:48:18 Quit petur (Changing host)
10:48:18 Join petur [0] (~petur@rockbox/developer/petur)
10:50:18 Join MrZeus_ [0] (~MrZeus@
10:53:40 Quit MrZeus (Ping timeout: 240 seconds)
10:54:06jhMikeSgevaerts: sure
10:54:10 Join robertd1 [0] (
10:55:00jhMikeSgevaerts: 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@
11:00:25 Quit elensil (Ping timeout: 256 seconds)
11:02:38 Join paulk-blaze [0] (
11:05:17 Quit xorly (Ping timeout: 252 seconds)
11:06:14 Join xorly [0] (~xorly@
11:09:28gevaertsjhMikeS: 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:56jhMikeSgevaerts: 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:19jhMikeSopen could be hooked to the wrong stuff
11:14:10 Quit Bray90820 (Ping timeout: 240 seconds)
11:14:14gevaertssimulated, I think
11:14:20 Join Bray90820 [0] (
11:15:34gevaertsOK, 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@
11:17:58 Quit petur (Changing host)
11:17:58 Join petur [0] (~petur@rockbox/developer/petur)
11:18:41gevaertsAs in, I pass /tmp/wavy/wps/wavy.wps to checkwps, and it ends up looking for ./tmp/wavy/wps/wavy.wps
11:18:42jhMikeShmmm, I see a '.' being prepended
11:19:05jhMikeSthere's probably a reason, like no base dir being provided
11:20:29gevaertsThat one probably should be / instead of . I guess
11:20:57gevaertsOr would that break relative paths?
11:21:00*gevaerts tries
11:21:52jhMikeSjust ""?
11:22:36 Quit pamaury_ (Ping timeout: 248 seconds)
11:22:37gevaertsor "" work
11:22:46jhMikeS"" will just prepend nothing
11:23:16gevaerts"/" 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:48gevaertsRight, 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:12jhMikeSnormally it simulates in the simdisk directory and so rejects them
11:29:45jhMikeSand relative bits that would take you above the sim root would be clipped
11:30:09*gevaerts nods
11:30:47jhMikeSnot even sure why it builds that file for an external utility anyway
11:31:14gevaertsLooks like things work fine for checkwps if I comment out the absolute path check
11:31:30gevaertsMaybe add an #ifndef __PCTOOL__ around that?
11:31:30 Quit TorC (Read error: Connection reset by peer)
11:31:44gevaertsThe 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:19gevaertsjhMikeS: 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:59gevaertsI'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:39:23jhMikeSyou mean the ones that map regular posix calls to sim_*?
11:40:26gevaertsI 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:39jhMikeSI'm pretty sure I spent well over a week on them. It was completely redone
11:41:12gevaertsAh, then you know what they were like :)
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@
11:42:13 Quit petur (Changing host)
11:42:13 Join petur [0] (~petur@rockbox/developer/petur)
11:42:43gevaertsIf 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:50jhMikeSI'm trying to discern the true intent of using sim api functions
11:43:35jhMikeSsince really it only enforces native target-like behavior to parsing a path
11:45:47jhMikeSthen again, maybe you want that if parsing is supposed to be in the context of running on a target
11:48:14jhMikeSyou're supposed to run the tool with the cwd being "root"?
11:48:28gevaertsHmmm, database probably still needs a sim_root_dir of ".". It's supposed to be run from the target directory
11:49:03gevaertscheckwps on the other hand can (or could) be run from anywhere
11:49:30gevaertsSo for database the current behaviour is probably correct
11:49:33jhMikeSit sounds like it shouldn't be using sim_ functions at all
11:51:10 Join wodz [0] (
11:56:31 Join Senji [0] (~Senji@
12:00:22jhMikeSmaybe it should be an app build instead of a sim?
12:02:08 Quit Senji (Ping timeout: 258 seconds)
12:04:40gevaertscheckwps as an app build does indeed work
12:05:24gevaertsBut again, not sure about database. I *think* that one needs to have the sim's concept of a root directory
12:05:40gevaertsWhich means we have to split up __PCTOOL_ for those
12:08:55 Join bzed [0] (
12:13:21 Quit ZincAlloy (Quit: Leaving.)
12:15:17gevaertsI don't know for sure :)
12:16:01gevaertsI 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:26gevaertsI don't know if they will be correct if the sim logic isn't used
12:16:52gevaertsAnyway, assuming the database has to remain on sim logic, seems to fix things for me
12:16:57pamauryIt would be logical that the database stores absolute name and wps store relative names.
12:17:25gevaertsthat moves checkwps to app logic and leaves database on sim logic
12:17:52gevaerts(and re-adds win32 support for both, which is of course untested)
12:19:31jhMikeSI'm still trying to figure out how the old checkwps got its sim root
12:20:38gevaertsBy accident, probably :)
12:20:59gevaertsDid it actually use the sim_*() functions?
12:21:04jhMikeSis APPLICATION defined when building those?
12:21:51gevaertsIt isn't *now*
12:22:08 Quit paulk-blaze (Quit: Leaving)
12:22:27jhMikeSwait, so they used to define APPLICATION
12:23:10gevaertsNo idea :)
12:23:37gevaertsI know it's not defined now, but I didn't check the old code
12:26:53jhMikeSno need for sim_root_dir would explain it because it just defined as a noop
12:27:03jhMikeSwas defined
12:41:45***Saving seen data "./dancer.seen"
12:46:27 Join paulk-collins [0] (
12:48:37 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium
12:50:55jhMikeSgevaerts: Previously, CheckWPS didn't include sim file code at all
12:51:24jhMikeSit actually shouldn't be there
12:53:44jhMikeSand 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:10jhMikeSsim_* was SIMULATOR || DBTOOL
13:02:01 Join skapazzo [0] (~skapazzo@
13:11:43jhMikeSgevaerts: who does the honors? you did the patch and I think it's right
13:14:29gevaertsjhMikeS: go ahead. I'm a bit busy...
13:31:39fs-bluebotBuild Server message: New build round started. Revision 4f7fea2, 255 builds, 13 clients.
14:02:42 Quit xorly (Ping timeout: 245 seconds)
14:27:36gevaertsjhMikeS: 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@
14:34:02 Join TorC [0] (~TorC@fsf/member/TorC)
14:41:48***Saving seen data "./dancer.seen"
15:01:37*chrisjj sees This site can’t be reached took too long to respond.
15:02:24chrisjjWhich is no real surprise since forums. and themes have gone down just about every day for the last month.
15:02:49chrisjjWhat 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:07chrisjjAnd who would want to attack anyway?
15:06:31gevaertsThere is no DoS attack
15:17:34 Quit wodz (Quit: Ex-Chat)
15:17:54Bilgusbut but but oh yeah
15:24:04chrisjjOK, 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:39pamauryscorche: what is the apache bug ? It is because of an old apache installation or bad config ?
15:48:34gevaertspamaury: at this point I somehow doubt it's an apache issue
15:49:29gevaertsWhat 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:59pamaurydies as in ? reboots ? freeze ?
15:50:24gevaertsMy connection freezes and new connections time out
15:50:50chrisjjWhat, no watchdog to reset the server?? :-)
15:52:09pamaurygevaerts: that sounds like a hardware problem potentially
15:53:23gevaertsOr 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@
15:53:27 Quit petur (Changing host)
15:53:27 Join petur [0] (~petur@rockbox/developer/petur)
15:55:10pamaurywould a migration be complicated ? I don't mind hosting it if it helps. Because the forums are down a lot these days
15:56:12gevaertsNot 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:10chrisjjI 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:04pamaurychrisjj: did you benchmark lcd sleep vs no lcd sleep ?
16:05:14chrisjjNo. I'm still trying trying to benchmark memDFS. And failing due to BSoPO.
16:06:10chrisjjIf your lcd* are on the same base, I think the same problem will prevent me benchmarking them too.
16:06:22__builtinchrisjj: what the heck is a "BSoPO"?
16:06:40chrisjjBlack Screen of Power Off.
16:07:32chrisjjZEN builds since Dec are mysteriously spontaneously going to power-off state after anything from 3min to 3hr after clean boot.
16:08:02chrisjjDepends on some variables, but I haven't pinpointed them
16:08:38pamaurychrisjj: instead of benchmarking memdfs, then it would be better to find the offending commit don't you think ?
16:08:57chrisjjBe my guest! :-)
16:09:01chrisjjOr tell me how to.
16:10:09pamaurywhat is the last know working commit again ?
16:10:14chrisjjRe 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:42chrisjjThe last known (to me) /build/ free from BSoPO is lcd_fix - 45697a0bf-161212.
16:12:41chrisjjAnd 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:52pamaury_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:53fs-bluebotGerrit review #1503 at : imx233: disable watchdog for debugging (DON'T PUSH) by Amaury Pouly
16:20:18chrisjjFeature suggestion: Setting to disable reset on watchdog.
16:20:47chrisjj'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:13fs-bluebotGerrit review #1503 at : imx233: disable watchdog for debugging (DON'T PUSH) by Amaury Pouly
16:23:36pamaury_chrisjj: please test
16:24:53 Join amayer [0] (
16:29:51chrisjjOK, 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:10chrisjjI.e. how can I determine whether a default-settings ZEN on charge on PC in non-USB-mode is getting watchdog reboots?
16:31:40chrisjjNot that default settings means backlight slept.
16:31:41pamaury_I can send you a build with HEAD + no watchdog if that helps
16:31:51pamaury_if that's what you want
16:32:38chrisjjPerhaps 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:57chrisjjThanks, but if there's an answer I can apply without changing any of the current four test devices, it would be good.
16:34:53chrisjjs/Thanks, but/Thanks for that build offer, but/
16:35:38pamaury_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:19chrisjjAh, 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:41chrisjjpamaury: 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:41pamauryof course
16:58:57*chrisjj is leaving nothing to chance.
16:59:22chrisjjI 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:19chrisjj(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:37chrisjjI 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:01chrisjjI shall empty a battery and retry.
17:03:03chrisjjThe comment the other day that firmware upgraders often require full charge got me thinking.
17:03:05pamauryit could also be a hard crash of the hardware
17:03:41pamaurya VDDD or other power rail brownout can do that
17:04:12chrisjjAny known way that this watchdog angering could occur at low charge and not high?
17:05:09chrisjjE.g. on a switch from the OF charger to the RB BL charger, or RB app charger?
17:05:28pamaurychrisjj: 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:51chrisjjI'm not obsessing on memDFS. This BSoPO is all over recent builds.
17:05:54pamauryremoving mem dfs from the equation can only make it simpler
17:06:10chrisjjI have done. Problem remained.
17:06:27pamauryI sent you a build with no watchdog, did you test it ?
17:06:44chrisjjNot yet. As I said, I'm trying to conserve devices.
17:07:27chrisjjI have only six free for RB testing and am about to send you two.
17:09:16pamauryI don't understand what you are trying to do by testing a build that we know fail
17:11:16chrisjjI'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:06chrisjjIf you know a better way, do say.
17:12:07pamauryI still don't understand: strart the device, play a huge playlist, check in 6 hours if the device is still running
17:13:27pamauryand check battery_bench and/or the running time in the system menu
17:13:46pamaury(since on reset, battery bench will not restart and the running time will be cleared)
17:14:22chrisjjThat'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:35pamaurythen 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:42pamaury* 100%
17:16:04chrisjjI 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:28chrisjjAre you sure running time is reliably cleared by watchdog reset?
17:17:48pamauryunless 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:06pamaurybut otherwise by playback wouldn't be enough ?
17:18:20chrisjjFWIW (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:35pamauryif the device resets, playback is not restarted
17:18:55pamaurythus: playback => no reset, no playback => reset/crash
17:19:12chrisjjSorry, our [16:18]'s crossed and my [16:18] was about Running Time, not playback.
17:19:36pamauryI'm saying that I don't understand why you don't simply use playback
17:19:51pamaurythat'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:55pamaurythen maybe it's the cumulative running time
17:21:12gevaertsI believe (not sure!) it should be the time since it was last charged
17:21:28pamauryah that would make sense
17:21:58gevaertsIIRC it's stored in nvram, which is simulated on most targets, which means it might not be updated if the device crashes
17:22:02pamaurymanual says:
17:22:05pamaury Running Time:
17:22:05pamaury 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:23chrisjjpamaury, 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:33chrisjjs/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:15chrisjjHowever, we can see how far we get with playback.
17:32:25pamauryif the device can crash when no playing then it crash when playing
17:32:36pamaury*it can crash when playing
17:33:34pamauryI 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:38chrisjjI'll test more.
17:35:48chrisjjme goes AFK.
17:39:38pixelmawell, 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@
18:00:11 Quit pamaury (Remote host closed the connection)
18:17:51 Join Guest38272 [0] (2e7df91b@gateway/web/freenode/ip.
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@
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] (
19:17:48 Join lebellium [0] (
19:19:56lebelliumgevaerts: thanks for the theme site
19:20:21gevaertsOh, it's back up?
19:20:39 Quit JdGordon (Ping timeout: 240 seconds)
19:21:54 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
19:25:08gevaertsThe good thing is that I don't have to touch it anymore, so it might not die :)
19:26:05lebelliumthat's a good fix
19:27:12__builtinhas anyone seen yet?
19:28:29__builtinit doesn't look like it's running rockbox
19:28:59lebelliumit was unclear if it should at release time
19:30:54lebelliumI assume the question is: does it have the sufficient SoC for a future port
19:32:09lebellium"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:54pamauryis the build server dead ?
20:05:10pamauryah 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:49lebelliumit will probably be hard to break your own record :)
20:13:59__builtinwe should probably stage a Turing test just to make sure pamaury's human :P
20:28:50pamaury[Saint]: I know you care about settings, would you mind telling me what you think about g#1486 ?
20:28:52fs-bluebotGerrit review #1486 at : Implement speaker enable/disable on jack (un)plug by Amaury Pouly
20:30:57 Join girafe [0] (
20:41:55***Saving seen data "./dancer.seen"
21:10:39__builtinpetur: your build client seems to be acting up, could you take a look?;type=samsungyh820sim
21:10:42__builtinwhois petur
21:11:29 Join ungali [0] (
21:11:29 Quit ungali (Changing host)
21:11:29 Join ungali [0] (ungali@unaffiliated/ungali)
21:24:52 Join xorly [0] (
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:22petur__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@
23:08:22chrisjjpixelma, 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:32chrisjjAnd 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:31chrisjjWorkaround: after resetting Top Time, press Back twice. Once is insufficient.
23:16:19pamauryif 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:35pamauryof course on reset you loose everything, which is not very surprising
23:25:52 Part robertd1
23:35:57pixelmachrisjj: 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)

Previous day | Next day