--- Log for 01.12.116 Server: card.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 12 hours and 41 minutes ago 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.03 # ok now this odd, the compilers optimizes strcat(glyph_path, ".gc"); 00.05.03 # into 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.17 # ah, it supports it but it is still one of those armv6 where it is disabled unless the OS enables it i think 00.17.18 # That's a quantum computer, I think 00.18.52 # we should port rockbox to use qubit 00.24.04 # I am getting close :) 00.24.27 # a damn, now it crashes later when displaying the main menu... 00.28.25 # does 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.47 # Hi Bilgus. Been meaning to ask you something. 00.53.46 # What 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.37 # look above^^ 00.58.49 Quit tracktheripper (Ping timeout: 260 seconds) 00.58.53 # Bilgus: 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.04.52 Join smoke_fumus [0] (~smoke_fum@dynamic-vpdn-93-125-13-169.telecom.by) 01.06.16 # I'm blind okay. 01.09.15 # Bilgus: 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.15 # So solving that first problem just revealed a new one. 01.10.45 # Does the device have a log that might shed light into this? 01.10.52 # well 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.01 # WELL... 01.11.33 # you can enable a logging build but no clue if that particular thing is logged 01.12.08 # Any ideas to see if the cause of the momentary silence is decode performance related or not? 01.13.23 # I don't have enough exp with rockbox to answer that but I bet someone else might 01.13.49 # Alright well thanks again. 01.17.17 Nick imdyinscoob is now known as ruhan (uid76353@gateway/web/irccloud.com/x-ifycdvbtigdeuvkk) 01.17.59 # I don't see any logf calls in the opus decoder 01.18.22 # you'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.07 # Got some fun cut out for me then. 01.21.18 Quit fs-bluebot (Ping timeout: 252 seconds) 01.21.18 # I just figured out how to build the project tonight. 01.22.32 Quit bluebrother (Ping timeout: 245 seconds) 01.22.45 # looking 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.34 # Oh boy. 01.31.52 # <[Saint]> The codecs are a no man's land. The older the better. 01.31.55 # looks 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.55 # yeah 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.59 # Miles: https://github.com/Rockbox/rockbox/blob/1f8ea9fe27313228e5df67ce6447830b5c30e5e3/apps/buffering.c 01.43.56 # line 41 tells you what to do to get logf working 01.44.46 # looking 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.12 # I think the thing is this was all done with 20ms frame sizes in mind. 01.48.23 # And my Opus files all have 60ms packed frames. 01.48.40 # Well that's a wild guess anyway. 01.48.48 # <[Saint]> isn't 20ms the spec defined framesize? 01.49.00 # Yes. 01.49.08 # <[Saint]> do fucky things, get fucky things. 01.49.38 # Ikr, I still need to test with 20ms files and see if they play better. 01.49.44 # https://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.31 # so set up your logf build and see what you see so to speak 01.51.46 # well 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.55 # I 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.16 # Its yet to be determined if thats the cause anyway/ 01.52.24 Quit athidhep (Quit: athidhep) 01.53.08 # so when your audio stopped playing and you pressed a button did it start again? 01.53.27 # Oh no its only stopping for a half second now. 01.53.31 Join athidhep [0] (~afoakf@unaffiliated/athidhep) 01.53.34 # And resuming on its own. 01.53.50 Quit athidhep (Client Quit) 01.54.06 # have you tried with files on the device or only on sd-card? 01.54.24 # I didn't try with files on the device actually. 01.54.27 # I should do that. 01.54.31 # yes. 01.54.59 # my tests were all on device 01.55.32 # I swear I must have found the edgiest edge case ever. 01.55.45 # and 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.13 # Okay. So if I end up doing a log-enabled build where do I look for the log? 01.56.21 # 60 ms is spec-allowed. 01.56.24 # Just not default. 01.56.30 # Or used. 01.56.31 # Ever 01.56.45 # in the debug menu and it should allow you to write it to file 01.57.15 # K. 02.02.25 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 02.04.01 # Libopus 1.2 is gonna allow packed frames up to 120 ms. 02.04.28 # So 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.18 # For 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.05 # there is clearly 8 people using opus 02.11.05 Quit ZincAlloy (Quit: Leaving.) 02.13.06 # opus.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.04 # so 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.21 # Xiph 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.45 # Yeah I struggle to imagine the utility. 02.24.56 Quit krnlyng (Ping timeout: 268 seconds) 02.26.19 # It was a core requirement of CELT long before the opus project too. 02.27.15 # Possibly the main reason for its creation. 02.27.42 # *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.45 Join Bilgus_ [0] (4cf32773@gateway/web/freenode/ip.76.243.39.115) 03.03.19 # 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.14 # Will test at some point. 03.07.34 # Probably tonight unless I'm busy. 03.07.43 # I just only use my Clip at work. 03.19.54 *** Saving seen data "./dancer.seen" 03.25.54 # ame: 03.26.10 # same 03.26.27 Quit rela (Read error: Connection reset by peer) 03.26.35 # perfect player for that 03.27.09 Join rela [0] (~x@pdpc/supporter/active/rela) 03.30.59 # Yep. 03.31.15 # They need to manufacture more Clips. 03.31.18 # Just for me. 03.33.03 # I recently discovered that there was (is?) a prison version of the clip 03.33.37 # http://www.head-fi.org/t/658420/check-it-out-sansa-clip-from-a-us-prison 03.34.58 # Wow, 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.55 # Huh. Wonder if you can RB those. 03.48.14 # And 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.46 # Need 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.24 # 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.33 # What'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.49 # :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.37 # Secondly, has anyone here ever swallowed a CLip+ whole. 03.52.41 # And how'd it go? 03.53.52 # You 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.28 # I had high hopes for rockchip Agptek clone but doesn't seem to be happening 03.58.03 # Didn't the makers of the SoC in all the Sansa devices contact Rockbox about making a player with RB in mind? 03.58.16 # That would have been way before me time so idk anything else about it. 04.01.01 # Here's that old wiki page... 04.01.02 # https://www.rockbox.org/wiki/AustriaMicrosystems 04.01.24 # Anybody 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.18 # I'm off for the night 04.25.31 # agreed those are very interesting reads 04.28.26 # * [Saint] looks at Bilgus and Miles suspiciously 04.28.30 # nah 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.19 # plus this nick has been here since i logged on at 5:03 04.30.00 Quit Miles (Ping timeout: 260 seconds) 04.30.04 # and miles is a canuk 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.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.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.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.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.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.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.18 # [Saint]: opus is a low latency codec aimed at things like telecommunications 11.36.57 # so they made it scalable down to 5 ms (IIRC), mostly by having small packets and shrinking the size of each transform window 11.37.45 # i 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.05 # although 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.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.08.47 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 13.13.59 # I 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.27 # saratoga: have you tried putting the file on a SD-Card? 13.17.01 # ChristW: 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.57 # Ah, 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.59 # Ahoy. 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.51 # Bilgus: no but i doubt it matters unless there is a problem with a specific sd card 13.34.33 # sans-ai: isn't make rocks just everything in the plugins folder? 13.35.59 # saratoga: I thought so. But simply adding a new .c file doesn't build it (I think). 13.36.11 # does it build at all ? 13.36.16 # e.g. with make 13.36.38 # Is it in SOURCES? 13.37.19 # I haven't tried just "make", tbh. 13.38.19 # if you're just asking how to add a plugin, you need to put it in SOUCES 13.38.24 # or SUBDIRS 13.38.30 # gevaerts: no, let me look at the SOURCES files. I just don't know "make" very well 13.40.03 # make ultimately goes through all the SOURCES/SUBDIRS folders to figure out what should be compiled 13.40.10 # if its not listed its not compiled 13.43.38 Join rela_ [0] (~x@p200300764D282D00802C68DA2A07A1A5.dip0.t-ipconnect.de) 13.46.18 # Ah 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.57 # https://www.rockbox.org/wiki/HowtoWritePlugins 13.50.48 # Wow. Did not see it there before. Clearly my bad. 13.54.39 Quit saratoga (Ping timeout: 260 seconds) 14.04.44 Join Bilgus [0] (~Bilgus@108.123.27.240) 14.05.51 # CHRISTW 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.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.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.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.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.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.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.23 # dammit, 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.09 # yeah, I think rockbox gets killed by a signal, but I don't know how to get more information, like the address 20.50.38 # I naively expected rockbox to panic on uncaught signal 20.52.06 # pamaury 20.52.57 # johnb2: yes? 20.53.06 # I 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.40 # I see a lot of 4xx on Ebay these days. 20.54.41 # johnb2: 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.56 # but if you want to buy one for you, buy one of those three 20.55.03 # (in the 4xx series I mean) 20.55.44 # and if I was looking for one with a sdcard slot? 20.56.14 # A15 20.56.15 # there are very few players with those 20.56.21 # A15 seems the only choice 20.56.29 # lebellium: ah you were faster :-p 20.56.55 # or A25 20.57.28 # ok, thanks. I think I read the A15 has ~5 Ohm headphone impedance. 20.58.12 # or A30 20.58.17 # always more expensive :D 20.58.46 # or of the fancy 600€ Sony players 20.59.30 # That's beyond of what I want to spend for another Toy/DAP ;-) 21.09.30 # ahhhhhh, I feel much better with the reasurring white panic screen :D 21.10.15 # normal users are rather scared when they see the panic screen 21.10.22 # that's the difference with devs :D 21.12.19 Quit akaWolf (Ping timeout: 248 seconds) 21.17.56 # lebellium: yes :) 21.19.06 Quit alexweissman (Remote host closed the connection) 21.20.18 *** Saving seen data "./dancer.seen" 21.22.32 # ok 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.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.53 # pamaury: If you could build usb-serial module maybe you could run rockbox in gdbserver on sony? 22.31.44 # wodz: 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.25 # also I'm not sure that building a usb serial module will be easy 22.32.33 # pamaury: 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.50 # I guess I'm back to printf/exit debugging, something crashes hard in do_menu apparently 22.42.01 # <__builtin> hey, is there a way to render a string to a in-memory bitmap? 22.42.15 # <__builtin> instead of the lcd framebuffer 22.43.12 # pamaury: 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.42 # pamaury: gui_synclist_speak_item(&lists); 22.59.58 # Bilgus: why this in particular ? 23.01.13 Quit johnb2 (Ping timeout: 250 seconds) 23.01.29 # because of the virtual pointers 23.02.32 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) 23.02.48 # nope 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.00 # I'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.08 # [Saint]: I already had a look at the database, I promised myself to never do that again 23.16.21 # buflib 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.24 # buflib is hard to understand because memory allocation is fundamentally ugly I would say 23.18.56 # at least I know what it does and how it is supposed to do it. For the database, it's a complete mess 23.19.43 # haha, 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.00 # this 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.56 # [Saint]: no idea, it crashes when displaying the root menu 23.22.23 # and 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.25 # but 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.34 # I 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.39 # ok.. 23.23.45 # 240x320 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.40 # yeah, 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.47 # [Saint]: is renaming cabbiev2.cfg enough? 23.25.53 # <[Saint]> Yes. 23.25.57 # [Saint]: I'm 100% there is 23.26.06 # I think it's safe to say that ;) 23.26.52 # [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.13 # yeah :-p so still digging 23.30.01 # so the menu_item_ex->menu_callback is garbage basically 23.34.12 # [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.12 # I'm afraid this is lower level 23.42.33 # wonder if the callbacks are using p2id 23.43.33 # ok so clearly there is some stack corruption 23.43.48 # a local variable went from a nice shiny valid address to total garbage 23.45.45 # or maybe not, arg this is some confusing 23.46.45 # well if it gets totally annoying put a var right after the stack and check for corruption after every call 23.47.23 # Bilgus: every test take 2min, so I'm doing what I can 23.50.08 # http://embeddedgurus.com/stack-overflow/2007/06/understanding-stack-overflow/ 6th comment down assumin your compiler has pragma directives 23.51.19 # if 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.06 # ick 23.56.16 # hum, 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