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 2016-12-01

00:00:51 Quit nlogex (Ping timeout: 248 seconds)
00:01:19 Quit Senji (Ping timeout: 246 seconds)
00:02:40 Join nlogex [0] (~filip@CPEa84e3f5c8563-CMa84e3f5c8560.cpe.net.fido.ca)
00:05:03pamauryok now this odd, the compilers optimizes strcat(glyph_path, ".gc");
00:05:03pamauryinto an unaligned dword write
00:10:04 Join tracktheripper [0] (4d61f5e5@gateway/web/freenode/ip.77.97.245.229)
00:16:30*pamaury is confused about arm1176, the documents says both that it supports unaligned accesses and that it does not
00:17:17pamauryah, it supports it but it is still one of those armv6 where it is disabled unless the OS enables it i think
00:17:18gevaertsThat's a quantum computer, I think
00:18:52pamaurywe should port rockbox to use qubit
00:24:04pamauryI am getting close :)
00:24:27pamaurya damn, now it crashes later when displaying the main menu...
00:28:25Bilgusdoes the first item get displayed before it does?
00:31:23 Quit pamaury (Ping timeout: 250 seconds)
00:41:08 Part robertd1
00:48:42 Nick [Saint] is now known as [Taint] (~sinner@rockbox/staff/saint)
00:49:05 Nick [Taint] is now known as [Saint] (~sinner@rockbox/staff/saint)
00:52:47MilesHi Bilgus. Been meaning to ask you something.
00:53:46MilesWhat files did you change in the source tree when you made those tweaks to CPU boosting for me?
00:55:39 Quit ender` (Quit: A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. — Douglas Adams)
00:56:37Bilguslook above^^
00:58:49 Quit tracktheripper (Ping timeout: 260 seconds)
00:58:53MilesBilgus: Oh missed you coming in. Thanks.
00:59:22[Saint]your client doesn't highlight?
00:59:28[Saint]He mentioned you by name.
01:00
01:04:52 Join smoke_fumus [0] (~smoke_fum@dynamic-vpdn-93-125-13-169.telecom.by)
01:06:16MilesI'm blind okay.
01:09:15MilesBilgus: Ah so that was just for GUI and not decoding related. So good news is that yes, I stopped having the buttons lock up on me. Bad news is that audio still stops once in a while.
01:10:15MilesSo solving that first problem just revealed a new one.
01:10:45MilesDoes the device have a log that might shed light into this?
01:10:52Bilguswell that makes sense since it is only going to boost on button presses, next i'd look for the boost for the codec
01:11:01BilgusWELL...
01:11:33Bilgusyou can enable a logging build but no clue if that particular thing is logged
01:12:08MilesAny ideas to see if the cause of the momentary silence is decode performance related or not?
01:13:23BilgusI don't have enough exp with rockbox to answer that but I bet someone else might
01:13:49MilesAlright well thanks again.
01:17:17 Nick imdyinscoob is now known as ruhan (uid76353@gateway/web/irccloud.com/x-ifycdvbtigdeuvkk)
01:17:59BilgusI don't see any logf calls in the opus decoder
01:18:22Bilgusyou'd have to place some in there at key points
01:18:57 Join fs-bluebot_ [0] (~fs-bluebo@xd9bafcfe.dyn.telefonica.de)
01:19:53***Saving seen data "./dancer.seen"
01:21:07MilesGot some fun cut out for me then.
01:21:18 Quit fs-bluebot (Ping timeout: 252 seconds)
01:21:18MilesI just figured out how to build the project tonight.
01:22:32 Quit bluebrother (Ping timeout: 245 seconds)
01:22:45Bilguslooking in rockbox/lib/rbcodec/codecs/libopus that is some seriously hairy code
01:24:37 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
01:26:00[Saint]Bilgus: the lame stuff, IMO, is worse.
01:26:41[Saint]If you're like me and get easily terrified by esoteric ARM ASM and foolishly creative math trickery.
01:30:34MilesOh boy.
01:31:52[Saint]The codecs are a no man's land. The older the better.
01:31:55Bilguslooks like fun :p
01:32:20[Saint]With age, comes more opportunity for 'Y'know what, I'm sure that loop could be two or three cycles tighter...'
01:32:40[Saint]I think saratoga is responsible for most of that.
01:33:27[Saint]the fft magic can also be terrifying/beautiful.
01:33:55Bilgusyeah it is funny how optimizations get more and more hard to understand as time goes on
01:34:20[Saint]there's at least a few points I just stare at occasionally.
01:34:25[Saint]like fine modern art.
01:42:59BilgusMiles: https://github.com/Rockbox/rockbox/blob/1f8ea9fe27313228e5df67ce6447830b5c30e5e3/apps/buffering.c
01:43:56Bilgusline 41 tells you what to do to get logf working
01:44:46Bilguslooking at the buffering code it boosts cpu when it is filling and unboosts when it is done so I'd say that probably isn't the issue
01:47:26[Saint]unless maybe if it was fucking up setting low and high watermarks?
01:48:12MilesI think the thing is this was all done with 20ms frame sizes in mind.
01:48:23MilesAnd my Opus files all have 60ms packed frames.
01:48:40MilesWell that's a wild guess anyway.
01:48:48[Saint]isn't 20ms the spec defined framesize?
01:49:00MilesYes.
01:49:08[Saint]do fucky things, get fucky things.
01:49:38MilesIkr, I still need to test with 20ms files and see if they play better.
01:49:44Bilgushttps://github.com/Rockbox/rockbox/blob/1f8ea9fe27313228e5df67ce6447830b5c30e5e3/apps/playback.c line 1182 logf("last track finished buffering");
01:49:57[Saint]I would expect a number of other codecs to bounce in weird ways if you disregard a cleanly defined spec.
01:50:20[Saint]I'm kinda surprised it even attempted it. Not sure if accident or deliberate.
01:50:31Bilgusso set up your logf build and see what you see so to speak
01:51:46Bilguswell if that turns out to fix it i'd say a warning is in order, oddly though with 12 hrs on actual and 24+ in sim I saw nothing.
01:51:55MilesI just had the framesize set to 60 out of habit because it's worth it under certain super-low-bitrate cirumstances. There was no real reason for it with ~96 kb/s music.
01:52:16MilesIts yet to be determined if thats the cause anyway/
01:52:24 Quit athidhep (Quit: athidhep)
01:53:08Bilgusso when your audio stopped playing and you pressed a button did it start again?
01:53:27MilesOh no its only stopping for a half second now.
01:53:31 Join athidhep [0] (~afoakf@unaffiliated/athidhep)
01:53:34MilesAnd resuming on its own.
01:53:50 Quit athidhep (Client Quit)
01:54:06Bilgushave you tried with files on the device or only on sd-card?
01:54:24MilesI didn't try with files on the device actually.
01:54:27MilesI should do that.
01:54:31Bilgusyes.
01:54:59Bilgusmy tests were all on device
01:55:32MilesI swear I must have found the edgiest edge case ever.
01:55:45Bilgusand then if that works out i'd try a different sd-card maybe higher ( or lower) class
01:56:04[Saint]why does the encoder even allow an out-of-spec framesize?
01:56:11[Saint]I think _that_ is the issue.
01:56:13MilesOkay. So if I end up doing a log-enabled build where do I look for the log?
01:56:21Miles60 ms is spec-allowed.
01:56:24MilesJust not default.
01:56:30MilesOr used.
01:56:31MilesEver
01:56:45Bilgusin the debug menu and it should allow you to write it to file
01:57:15MilesK.
02:00
02:02:25 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
02:04:01MilesLibopus 1.2 is gonna allow packed frames up to 120 ms.
02:04:28MilesSo if framesize actualyl does turn out to be a problem, better to find out now.
02:06:14[Saint]Hmmm...OK. My mistake. My knowledge of celt/libcelt/libopus is dated by a number of years.
02:06:18MilesFor like the one other person who uses it.
02:07:36[Saint]pretty sure our opus decoder was built off the spec defined at the time. but that's the only shred I have to support my claim that 20ms framesize was the way and the light.
02:08:03[Saint]well, without digging a lot.
02:11:05Bilgusthere is clearly 8 people using opus
02:11:05 Quit ZincAlloy (Quit: Leaving.)
02:13:06Bilgusopus.h * @li Sampling rates from 8 to 48 kHz * @li Bit-rates from 6 kb/s to 510 kb/s * @li Support for both constant bit-rate (CBR) and variable bit-rate (VBR) * @li Audio bandwidth from narrowband to full-band * @li Support for speech and music * @li Support for mono and stereo * @li Support for multichannel (up to 255 channels) * @li Frame sizes from 2.5 ms to 60 ms * @li Good loss robustness and packet loss concealment (
02:14:04Bilgusso 60ms is allowed according to this
02:15:45[Saint]the fuck are you going to do with a ~2, let alone .5ms resolution, framesize?
02:15:49[Saint]and...why?
02:17:21MilesXiph was really hellbent on supporting super low latency scenarios like remote band practice.
02:18:16[Saint]all the idie studios out there directly hooked to fucking DARPAnet will be pleased.
02:18:45MilesYeah I struggle to imagine the utility.
02:24:56 Quit krnlyng (Ping timeout: 268 seconds)
02:26:19MilesIt was a core requirement of CELT long before the opus project too.
02:27:15MilesPossibly the main reason for its creation.
02:27:42Miles*shrugs*
02:36:46 Join krnlyng [0] (~liar@178.112.224.139.wireless.dyn.drei.com)
02:59:50 Join B [0] (4cf32773@gateway/web/freenode/ip.76.243.39.115)
02:59:59 Quit B (Client Quit)
03:00
03:00:45 Join Bilgus_ [0] (4cf32773@gateway/web/freenode/ip.76.243.39.115)
03:03:19Bilgus_Miles I notice the sd card has a thread priority of PRIORITY_USER_INTERFACE whereas buffering switches between PRIORITY_USER_INTERFACE and PRIORITY_BUFFERING which is higher, with the large files having issues I'm very interested if switching to internal storage helps
03:07:14MilesWill test at some point.
03:07:34MilesProbably tonight unless I'm busy.
03:07:43MilesI just only use my Clip at work.
03:19:54***Saving seen data "./dancer.seen"
03:25:54Bilgus_ame:
03:26:10Bilgus_same
03:26:27 Quit rela (Read error: Connection reset by peer)
03:26:35Bilgus_perfect player for that
03:27:09 Join rela [0] (~x@pdpc/supporter/active/rela)
03:30:59MilesYep.
03:31:15MilesThey need to manufacture more Clips.
03:31:18MilesJust for me.
03:33:03Bilgus_I recently discovered that there was (is?) a prison version of the clip
03:33:37Bilgus_http://www.head-fi.org/t/658420/check-it-out-sansa-clip-from-a-us-prison
03:34:58MilesWow, news to me.
03:44:55[Saint]there's at least two modified prison firmwares I've seen.
03:45:04[Saint]possibly from the same outfit.
03:45:15[Saint]I've seen both british and US prison variants.
03:47:55MilesHuh. Wonder if you can RB those.
03:48:14MilesAnd if they're otherwise equivalent to the civilian version.
03:48:42[Saint]You can. Not conventionally. And they are.
03:48:52[Saint]The fuckery is entirely software based.
03:49:44[Saint]They disable updating via conventional methods, either via Sandisk application or sdcard.
03:49:46MilesNeed to buy a spare unit before they get even more expensive.
03:50:09[Saint]But...we have the (really fucky and unreliable" SansaAMS recovery method.
03:50:21[Saint]s/"/)/
03:50:24Bilgus_I wonder if they are still being made I'd like to get my hands on a few just not in the conventional way :p
03:51:09[Saint]Bilgus: they don't make it out into the public often, because they make you buy them at a ridiculous price from the commissary.
03:51:33MilesWhat's the minimum crime I'd have to confess for to be inside long enough to save up for one of their prison Clips and immediately "lose" it?
03:51:49Miles:P
03:52:01[Saint]In the entire history of ever I have only ever talked a a person that has had one once. That was the british guy.
03:52:12[Saint]The US guy I can't recall how that happened.
03:52:37MilesSecondly, has anyone here ever swallowed a CLip+ whole.
03:52:41MilesAnd how'd it go?
03:53:52MilesYou know what maybe $100 on ebay from that israeli guy sitting on the last big stockpile isn't so bad upon further consideration.
03:56:28Bilgus_I had high hopes for rockchip Agptek clone but doesn't seem to be happening
03:58:03MilesDidn't the makers of the SoC in all the Sansa devices contact Rockbox about making a player with RB in mind?
03:58:16MilesThat would have been way before me time so idk anything else about it.
04:00
04:01:01MilesHere's that old wiki page...
04:01:02Mileshttps://www.rockbox.org/wiki/AustriaMicrosystems
04:01:24MilesAnybody know what the hell happened?
04:03:45 Quit Miles (Quit: Page closed)
04:08:07 Quit Bilgus_ (Quit: Page closed)
04:08:42[Saint]Now I'm gonna catch myself thinking that Miles and Bilgus are just two conflicting personalities in the same body...
04:11:15[Saint]If either of you read logs, I think the 'what the hell happened' was mainly interesting in being given a bunch of AMS data sheets that still make the rounds to this day.
04:12:41 Join Miles [0] (b8973faa@gateway/web/freenode/ip.184.151.63.170)
04:25:18MilesI'm off for the night
04:25:31Bilgusagreed those are very interesting reads
04:28:26*[Saint] looks at Bilgus and Miles suspiciously
04:28:30Bilgusnah I'm fine with mp3 and flac I don't like Mr. Holland
04:28:37[Saint]...I'm on to you!
04:28:41[Saint]*wags finger*
04:29:19Bilgusplus this nick has been here since i logged on at 5:03
04:30:00 Quit Miles (Ping timeout: 260 seconds)
04:30:04Bilgusand miles is a canuk
05:00
05:19:55***Saving seen data "./dancer.seen"
05:24:47 Quit The_Prospector (Quit: when in doubt, kernel panic)
05:30:06 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman)
06:00
06:22:24 Quit Bilgus (Quit: Page closed)
06:42:20 Quit nlogex (Ping timeout: 250 seconds)
06:42:39 Join Senji [0] (~Senji@85.187.103.250)
06:48:10 Join mxyzptlk [0] (~joe@va-184-5-255-226.dhcp.embarqhsd.net)
06:48:47 Quit TheSeven (Ping timeout: 245 seconds)
06:49:11 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
07:00
07:15:24 Join Senji_ [0] (~Senji@85.187.103.250)
07:17:56 Quit Senji (Ping timeout: 240 seconds)
07:19:58***Saving seen data "./dancer.seen"
07:27:32 Quit Bray90820_ (Ping timeout: 244 seconds)
07:33:53 Join Bray90820 [0] (~bray90820@50-83-212-56.client.mchsi.com)
07:55:27 Nick mxyzptlk is now known as mxyzplx (~joe@va-184-5-255-226.dhcp.embarqhsd.net)
08:00
08:14:25 Join ender` [0] (krneki@foo.eternallybored.org)
08:17:19 Quit alexweissman (Remote host closed the connection)
08:18:26 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net)
08:44:57 Quit puckipedia (Remote host closed the connection)
08:45:33 Quit alexweissman (Remote host closed the connection)
08:50:02 Join petur [0] (~petur@rockbox/developer/petur)
08:51:30 Join GodEater [0] (~whoknows@90.218.131.42)
08:51:30 Quit GodEater (Changing host)
08:51:30 Join GodEater [0] (~whoknows@rockbox/staff/GodEater)
08:55:05 Quit Bray90820 (Ping timeout: 246 seconds)
09:00
09:01:52 Quit GodEater (Quit: Coyote finally caught me)
09:02:05 Join GodEater [0] (~whoknows@90.218.131.42)
09:02:05 Quit GodEater (Changing host)
09:02:05 Join GodEater [0] (~whoknows@rockbox/staff/GodEater)
09:10:06 Join Bray90820 [0] (~bray90820@50-83-212-56.client.mchsi.com)
09:14:56 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
09:20:01***Saving seen data "./dancer.seen"
09:26:18 Quit CustosL1men (Ping timeout: 260 seconds)
09:26:43 Quit JdGordon (Ping timeout: 250 seconds)
09:27:37 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
09:30:30 Quit n17ikh (Ping timeout: 260 seconds)
09:30:57 Join CustosL1men [0] (~CustosLim@unaffiliated/cust0slim3n)
09:32:12 Join n17ikh [0] (~n17ikh@unaffiliated/n17ikh)
09:33:16 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
09:36:34 Quit uwe_mobile (Ping timeout: 260 seconds)
09:38:04 Join uwe_mobile [0] (~uwe@static.173.76.9.176.clients.your-server.de)
09:56:08 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net)
10:00
10:00:44 Quit alexweissman (Ping timeout: 260 seconds)
10:04:15 Quit pamaury (Ping timeout: 258 seconds)
10:05:42 Join elensil [0] (~edhelas@2001:1c02:1903:d800:451b:e3c5:f5c5:1baf)
10:22:28 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:7930:c025:e834:4c72)
10:42:15 Join Senji [0] (~Senji@85.187.103.250)
10:43:46 Join paulk-collins [0] (~paulk@gagarine.paulk.fr)
10:45:35 Quit Senji_ (Ping timeout: 250 seconds)
10:57:32 Join soap_ [0] (~soap@rockbox/staff/soap)
10:57:54 Quit soap (Read error: Connection reset by peer)
11:00
11:03:31 Quit megal0maniac (Killed (adams.freenode.net (Nickname regained by services)))
11:03:35 Join megal0maniac [0] (~megal0man@unaffiliated/megal0maniac)
11:04:09 Join tchan1 [0] (~tchan@c-50-129-174-2.hsd1.il.comcast.net)
11:04:23 Quit tchan (Ping timeout: 260 seconds)
11:04:23 Join athidhep [0] (~afoakf@S0106602ad06acd48.vc.shawcable.net)
11:04:24 Quit athidhep (Changing host)
11:04:24 Join athidhep [0] (~afoakf@unaffiliated/athidhep)
11:06:43 Join pamaury [0] (~quassel@wks-50-63.mpi-sws.org)
11:06:43 Quit pamaury (Changing host)
11:06:43 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
11:13:59 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
11:20:04***Saving seen data "./dancer.seen"
11:30:49 Join feoafka [0] (~afoakf@S0106602ad06acd48.vc.shawcable.net)
11:33:40 Quit prof_wolfff (Read error: Connection reset by peer)
11:35:45 Join saratoga [0] (3ee871ea@gateway/web/freenode/ip.62.232.113.234)
11:36:18saratoga[Saint]: opus is a low latency codec aimed at things like telecommunications
11:36:57saratogaso they made it scalable down to 5 ms (IIRC), mostly by having small packets and shrinking the size of each transform window
11:37:45saratogai think if long frames are the problem, decoding should probably be split to do some upper bound of data (maybe 20 ms) per pass and then yield if needed
11:38:05saratogaalthough the fact that i can't reproduce it on myself makes me wonder exactly what the conditions needed to reproduce the problem are
11:39:03 Quit athidhep (*.net *.split)
11:39:03 Quit duo8 (*.net *.split)
11:39:03 Quit TD-Linux (*.net *.split)
11:39:03 Quit alexbobp (*.net *.split)
11:39:03 Quit sbach_ (*.net *.split)
11:40:51 Join prosinz [0] (~adambomb@c-24-22-103-176.hsd1.wa.comcast.net)
11:41:55 Quit cohokiller673 (Ping timeout: 250 seconds)
11:43:29 Join duo8 [0] (~ZNC-SRV-H@27.76.255.1)
11:43:29 Join TD-Linux [0] (~Thomas@about/essy/indecisive/TD-Linux)
11:43:29 Join sbach_ [0] (~sbach@107.189.42.74)
11:43:29 Join alexbobp [0] (~alex@testificate.xen.prgmr.com)
11:49:49 Quit saratoga (Ping timeout: 260 seconds)
12:00
12:11:29 Join robertd1 [0] (~root@201.208.231.245)
12:22:59 Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com)
12:49:56 Quit scorche|sh (Ping timeout: 244 seconds)
13:00
13:08:47 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury)
13:13:59ChristW1I enabled the LOGF build on my iPod. Did I skim the code correctly to see that there should be a log file created on the hard disk somewhere? I would guess in the .rockbox folder?
13:14:02 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217)
13:14:31 Join sans-ai [0] (~san@x5ce7f0ac.dyn.telefonica.de)
13:15:27Bilgussaratoga: have you tried putting the file on a SD-Card?
13:17:01BilgusChristW: you need a logf enabled build, logf needs to be defined, then goto debug>menu and it will be there choose to write it to disk, I was discussing this with Miles about 12 hrs ago look back in the logs
13:17:18 Quit Bilgus (Client Quit)
13:17:57ChristW1Ah, ok, I will look. I did go to the debug menu, but it didn't leap to the eye.
13:20:08***Saving seen data "./dancer.seen"
13:21:59sans-aiAhoy. Where can I specify a new plugin/file to be built for "make rocks"?
13:22:37 Join Bray90820_ [0] (~bray90820@50-83-212-56.client.mchsi.com)
13:24:27 Quit ZincAlloy (Quit: Leaving.)
13:25:36 Quit Bray90820 (Ping timeout: 260 seconds)
13:27:40 Join saratoga [0] (3ee871ea@gateway/web/freenode/ip.62.232.113.234)
13:27:51saratogaBilgus: no but i doubt it matters unless there is a problem with a specific sd card
13:34:33saratogasans-ai: isn't make rocks just everything in the plugins folder?
13:35:59sans-aisaratoga: I thought so. But simply adding a new .c file doesn't build it (I think).
13:36:11saratogadoes it build at all ?
13:36:16saratogae.g. with make
13:36:38gevaertsIs it in SOURCES?
13:37:19sans-aiI haven't tried just "make", tbh.
13:38:19saratogaif you're just asking how to add a plugin, you need to put it in SOUCES
13:38:24saratogaor SUBDIRS
13:38:30sans-aigevaerts: no, let me look at the SOURCES files. I just don't know "make" very well
13:40:03saratogamake ultimately goes through all the SOURCES/SUBDIRS folders to figure out what should be compiled
13:40:10saratogaif its not listed its not compiled
13:43:38 Join rela_ [0] (~x@p200300764D282D00802C68DA2A07A1A5.dip0.t-ipconnect.de)
13:46:18sans-aiAh fantastic, it works. Is that info somewhere on the rockbox site? I tried looking there.
13:47:40 Quit rela (Ping timeout: 246 seconds)
13:47:57saratogahttps://www.rockbox.org/wiki/HowtoWritePlugins
13:50:48sans-aiWow. Did not see it there before. Clearly my bad.
13:54:39 Quit saratoga (Ping timeout: 260 seconds)
14:00
14:04:44 Join Bilgus [0] (~Bilgus@108.123.27.240)
14:05:51BilgusCHRISTW don't forget #define LOGF_ENABLE
14:07:04 Quit Bilgus (Remote host closed the connection)
14:11:49 Join Bilgus [0] (~Bilgus@108.123.27.240)
14:13:51 Quit Bilgus (Remote host closed the connection)
14:16:28 Join Senji_ [0] (~Senji@85.187.103.250)
14:19:27 Quit Senji (Ping timeout: 260 seconds)
14:22:16 Join Senji [0] (~Senji@85.187.103.250)
14:25:31 Quit Senji_ (Ping timeout: 260 seconds)
14:32:16 Quit rela_ (Quit: Leaving)
14:46:50 Part robertd1
14:50:05 Quit sans-ai (Quit: thanks)
15:00
15:20:11***Saving seen data "./dancer.seen"
15:26:15 Quit wodz (Ping timeout: 240 seconds)
15:45:04 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
16:00
16:43:16 Quit pamaury (Remote host closed the connection)
16:47:35 Quit pamaury_ (Ping timeout: 240 seconds)
16:54:12 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net)
17:00
17:02:32 Join TheLemonMan [0] (~root@unaffiliated/thelemonman)
17:08:29 Join nlogex [0] (~filip@CPEa84e3f5c8563-CMa84e3f5c8560.cpe.net.fido.ca)
17:20:15***Saving seen data "./dancer.seen"
17:33:42 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
17:35:19 Quit alucryd (Remote host closed the connection)
17:43:19 Quit petur (Read error: Connection reset by peer)
17:46:04 Quit Jinx (Quit: reboot)
18:00
18:12:04 Quit elensil (Remote host closed the connection)
18:26:47 Quit prof_wolfff (Ping timeout: 260 seconds)
18:37:24 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:f1f8:3fd:a99b:e08f)
18:42:42 Join puckipedia [0] (puck@puckipedia.com)
18:48:08 Join girafe [0] (~girafe@LFbn-1-8015-136.w90-112.abo.wanadoo.fr)
18:56:08 Join edhelas [0] (~edhelas@145.133.43.230)
19:00
19:07:07 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche)
19:10:54 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
19:20:16***Saving seen data "./dancer.seen"
19:30:03 Quit ChristW (Read error: Connection reset by peer)
19:30:04 Quit ChristW1 (Read error: Connection reset by peer)
19:32:36 Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr)
19:48:57 Quit nlogex (Ping timeout: 256 seconds)
20:00
20:09:32 Quit Senji (Read error: Connection reset by peer)
20:10:48 Join Senji [0] (~Senji@85.187.103.250)
20:11:10 Join petur [0] (~petur@rockbox/developer/petur)
20:13:35 Join Senji_ [0] (~Senji@85.187.103.250)
20:13:43 Join johnb3 [0] (~johnb2@pD957DAF3.dip0.t-ipconnect.de)
20:15:02 Join johnb2 [0] (~johnb2@pD957DAF3.dip0.t-ipconnect.de)
20:16:09 Quit edhelas (Quit: Leaving.)
20:16:41 Quit Senji (Ping timeout: 265 seconds)
20:18:16 Quit Senji_ (Ping timeout: 246 seconds)
20:23:29 Quit johnb3 (Ping timeout: 268 seconds)
20:24:30 Join Senji [0] (~Senji@85.187.103.250)
20:24:31 Quit michaelni (Ping timeout: 250 seconds)
20:27:11 Quit johnb2 (Ping timeout: 268 seconds)
20:27:24 Join johnb3 [0] (~johnb2@pD957DAF3.dip0.t-ipconnect.de)
20:34:08 Join nlogex [0] (~filip@CPEa84e3f5c8563-CMa84e3f5c8560.cpe.net.fido.ca)
20:35:55 Join rela [0] (~x@pdpc/supporter/active/rela)
20:37:11 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at)
20:40:46 Part johnb3
20:44:19 Join johnb2 [0] (~johnb2@pD957DAF3.dip0.t-ipconnect.de)
20:45:23pamaurydammit, sometimes debugging rockbox as an application seems harder than debugging on bare-metal
20:48:17[Saint]debugging with exit/printf? :)
20:48:30[Saint]...been there.
20:50:09pamauryyeah, I think rockbox gets killed by a signal, but I don't know how to get more information, like the address
20:50:38pamauryI naively expected rockbox to panic on uncaught signal
20:52:06johnb2pamaury
20:52:57pamauryjohnb2: yes?
20:53:06johnb2I think I remember you posting a list of Sony players with Linux as candidates for Rockbox, but I cannot find that link anymore.
20:53:40johnb2I see a lot of 4xx on Ebay these days.
20:54:41pamauryjohnb2: the interesting ones are 450, 460, 470. But I think we successfully bought all three, I have the 450 and 460 and wodz has the 470
20:54:56pamaurybut if you want to buy one for you, buy one of those three
20:55:03pamaury(in the 4xx series I mean)
20:55:44johnb2and if I was looking for one with a sdcard slot?
20:56:14lebelliumA15
20:56:15pamaurythere are very few players with those
20:56:21pamauryA15 seems the only choice
20:56:29pamaurylebellium: ah you were faster :-p
20:56:55lebelliumor A25
20:57:28johnb2ok, thanks. I think I read the A15 has ~5 Ohm headphone impedance.
20:58:12lebelliumor A30
20:58:17lebelliumalways more expensive :D
20:58:46pamauryor of the fancy 600€ Sony players
20:59:30johnb2That's beyond of what I want to spend for another Toy/DAP ;-)
21:00
21:09:30pamauryahhhhhh, I feel much better with the reasurring white panic screen :D
21:10:15lebelliumnormal users are rather scared when they see the panic screen
21:10:22lebelliumthat's the difference with devs :D
21:12:19 Quit akaWolf (Ping timeout: 248 seconds)
21:17:56pamaurylebellium: yes :)
21:19:06 Quit alexweissman (Remote host closed the connection)
21:20:18***Saving seen data "./dancer.seen"
21:22:32pamauryok so I get a segmentation fault, but it's not that easy to translate the address to something useful
21:27:43 Join alucryd [0] (~quassel@archlinux/developer/alucryd)
21:30:07 Quit [Saint] (Remote host closed the connection)
21:31:42 Join [Saint] [0] (~sinner@rockbox/staff/saint)
21:37:27 Quit nlogex (Quit: WeeChat 1.6)
22:00
22:00:19 Join edhelas [0] (~edhelas@145.133.43.230)
22:09:55 Quit edhelas (Ping timeout: 248 seconds)
22:13:46 Quit JanC (Ping timeout: 246 seconds)
22:15:11 Join alexweissman [0] (~alexweiss@149-160-181-89.dhcp-bl.indiana.edu)
22:15:30 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
22:22:07 Join JanC [0] (~janc@lugwv/member/JanC)
22:25:19 Quit paulk-collins (Quit: Leaving)
22:26:00 Join edhelas [0] (~edhelas@145.133.43.230)
22:27:33 Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl)
22:28:53wodzpamaury: If you could build usb-serial module maybe you could run rockbox in gdbserver on sony?
22:31:44pamaurywodz: I found a way to get the information using sigaction and ucontext_t, but this is useless, the pc address is clearly wrong, seems like a corruption
22:32:23 Join Bray90820 [0] (~bray90820@50-83-212-56.client.mchsi.com)
22:32:25pamauryalso I'm not sure that building a usb serial module will be easy
22:32:33wodzpamaury: gdbserver + serial gadget driver would be useful in the long run
22:34:46 Quit Bray90820_ (Ping timeout: 246 seconds)
22:36:01 Quit petur (Remote host closed the connection)
22:36:52 Join naleo [0] (~naleo@unaffiliated/naleo)
22:37:48 Quit johnb2 (Ping timeout: 265 seconds)
22:41:11*funman likes this idea
22:41:31 Join johnb2 [0] (~johnb2@pD957DAF3.dip0.t-ipconnect.de)
22:41:50pamauryI guess I'm back to printf/exit debugging, something crashes hard in do_menu apparently
22:42:01__builtinhey, is there a way to render a string to a in-memory bitmap?
22:42:15__builtininstead of the lcd framebuffer
22:43:12wodzpamaury: Looking at sony's kernel configuration it should be possible to build serial gadget driver.
22:50:41 Quit The_Prospector (Quit: when in doubt, kernel panic)
22:51:20 Quit alexweissman (Remote host closed the connection)
22:51:39 Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com)
22:54:25 Quit wodz (Quit: Leaving)
22:55:29 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217)
22:55:42Bilguspamaury: gui_synclist_speak_item(&lists);
22:59:58pamauryBilgus: why this in particular ?
23:00
23:01:13 Quit johnb2 (Ping timeout: 250 seconds)
23:01:29Bilgusbecause of the virtual pointers
23:02:32 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman)
23:02:48pamaurynope crashes in init_menu_lists
23:09:54[Saint]__builtin: errrr, instead of asking that question, might you like to try explaining your use case?
23:12:00pamauryI'm slowly digging further in menu.c and gui/list.c, I really prefer firmware/
23:12:31 Join alexweissman [0] (~alexweiss@149-160-181-89.dhcp-bl.indiana.edu)
23:15:41[Saint]pamaury: If you want to really feel like surling up into a ball and dying, take a look at the database and/or buflib magic.
23:15:53[Saint]s/surling/curling/
23:16:08pamaury[Saint]: I already had a look at the database, I promised myself to never do that again
23:16:21pamaurybuflib is much better in comparison
23:16:38 Quit girafe (Read error: Connection reset by peer)
23:17:46[Saint]You're not wrong, indeed. But 'much better in comparison' really allows a lot of wiggle room regarding what it is compared to.
23:17:47[Saint]Somewhat like, "Mussolini is a lot better in comparison to Hitler".
23:17:53[Saint];)
23:18:24pamaurybuflib is hard to understand because memory allocation is fundamentally ugly I would say
23:18:56pamauryat least I know what it does and how it is supposed to do it. For the database, it's a complete mess
23:19:43pamauryhaha, so get_menu_callback is returned a crap address that segfaults, now why is that??
23:20:19***Saving seen data "./dancer.seen"
23:20:28 Quit feoafka (Quit: feoafka)
23:20:52[Saint]I might have an idea.
23:21:00pamaurythis is really strange, this piece of code is heavily tested, someone would have noticed by now
23:21:06[Saint]Does "the crap address" differ wildly if you're using the fallback skin?
23:21:39[Saint]as opposed to cabbiev2 or any other arbitrary skin (which if I'm right should also differ wildly).
23:21:56pamaury[Saint]: no idea, it crashes when displaying the root menu
23:22:23pamauryand I haven't change any setting since I haven't gone past this point yet :)
23:23:09[Saint]nuke or rename the cabbiev2 directory.
23:23:25pamaurybut the address is semi-random: it's always the same but if I recompile the program with a slight change, it's completely different
23:23:34pamauryI suspect some uninitialised memory
23:23:38[Saint](this assumes you built the app with a resolution that allows for cabbiev2 to be pulled in)
23:23:39pamauryok..
23:23:45pamaury240x320
23:23:54[Saint]right, that'll allow for it. indeed.
23:24:16[Saint]themes only get pulled in if there's an exact resolution match, but I suspect I don't need to explain this to you.
23:24:40pamauryyeah, ok let me try to rename cabbiev2
23:25:44[Saint]I have suspected but not been able to actually track down or prove that there was a memory corruption and.or overflow issue in the skin engine for years and years and years.
23:25:47pamaury[Saint]: is renaming cabbiev2.cfg enough?
23:25:53[Saint]Yes.
23:25:57pamaury[Saint]: I'm 100% there is
23:26:06pamauryI think it's safe to say that ;)
23:26:52pamaury[Saint]: doesn't seem to help
23:27:27[Saint]OK, thanks. I kinda wish it did allow for it to progress through the boot process further.
23:27:40[Saint]But...that would've been too easy now, wouldn;t it? ;)
23:29:13pamauryyeah :-p so still digging
23:30:01pamauryso the menu_item_ex->menu_callback is garbage basically
23:34:12pamaury[Saint]: do you know a bit about menu.h and the menu structure ?
23:34:40 Join tracktheripper [0] (4d61f5e5@gateway/web/freenode/ip.77.97.245.229)
23:37:05[Saint]Only in the most literal sense I suppose. Like adding and removing menu structures and ensuring they are localized.
23:40:12pamauryI'm afraid this is lower level
23:42:33Bilguswonder if the callbacks are using p2id
23:43:33pamauryok so clearly there is some stack corruption
23:43:48pamaurya local variable went from a nice shiny valid address to total garbage
23:45:45pamauryor maybe not, arg this is some confusing
23:46:45Bilguswell if it gets totally annoying put a var right after the stack and check for corruption after every call
23:47:23pamauryBilgus: every test take 2min, so I'm doing what I can
23:50:08Bilgushttp://embeddedgurus.com/stack-overflow/2007/06/understanding-stack-overflow/ 6th comment down assumin your compiler has pragma directives
23:51:19pamauryif it's a corruption, it's probably not a stack overflow, more likely a buffer overflow corruption neighbour variable, but this menu code is just so horrible to follow
23:52:06Bilgusick
23:56:16pamauryhum, now it's looking as if the root menu itself is not valid, and since of course it is loaded from a cfg, this is very easy to track down

Previous day | Next day