--- Log for 04.11.116 Server: karatkievich.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 27 days and 3 hours ago 00.00.47 # <[Saint]> personally, yes. 00.01.08 # <[Saint]> that aligns itself better to the way the database scan selector functions. 00.01.41 # <[Saint]> and it would make it easier if you wanted to enable it for 'all directions' or so. 00.02.22 # <[Saint]> (because that selector allows for selecting or deselecting all of a subcategory, one may as well use it) 00.02.45 # <[Saint]> I don't think there's much room to use subcategories outside of the DPAD though. 00.03.03 # <[Saint]> up/down/left/right is the only group you can really make. 00.03.44 # <[Saint]> but it would still make selection of them easier if the user wanted all of them, or all but all of them. one section instead of four for either case. 00.03.49 # <[Saint]> Bilgus: ^ 00.04.55 # two categories sounds kind of pointless though 00.06.59 Quit APLU (Ping timeout: 260 seconds) 00.13.39 # <[Saint]> I think it would be worth it to section off the DPAD in to it's own group. 00.13.50 Join MulX [0] (~mulx@eva.aplu.fr) 00.14.09 # <[Saint]> if for no other reason than it would make it easier to select or deselect each of the directional keys by a factor of four. 00.14.53 # <[Saint]> I think a majority of people are going to want to enable or disable this for all or none of the DPAD. 00.14.55 Join Link8 [0] (~me@546AC6B1.cm-12-3d.dynamic.ziggo.nl) 00.15.02 # <[Saint]> So that makes a subgroup useful. 00.15.15 Nick MulX is now known as APLU (~mulx@eva.aplu.fr) 00.16.41 Quit Link8 (Remote host closed the connection) 00.17.36 Join Link8 [0] (~me@546AC6B1.cm-12-3d.dynamic.ziggo.nl) 00.19.56 # looking at tree.c tagtree.c and filetree.c it looks to me like I could reuse the vast majority as is and just load the tree context beyond that I might as well start from scratch as it is needlessly complex 00.25.44 Quit paulk-collins (Quit: Leaving) 00.32.00 Part robertd1 00.36.02 Quit ender` (Quit: Q: What's the difference between ignorance and apathy? A: I neither know, nor care.) 00.36.02 Quit Link8 (Read error: Connection reset by peer) 00.36.47 Join Link8 [0] (~me@546AC6B1.cm-12-3d.dynamic.ziggo.nl) 00.39.34 Join alexweissman [0] (~alexweiss@2602:306:3893:2620:3df7:60e5:6786:4a44) 00.40.35 Join robertd1 [0] (~root@201.211.53.103) 00.41.45 Part robertd1 00.43.06 Join Strife1989 [0] (~quassel@adsl-98-80-191-93.mcn.bellsouth.net) 00.45.17 Quit Link8 (Ping timeout: 256 seconds) 00.46.50 *** Saving seen data "./dancer.seen" 00.46.56 Quit Strife89 (Ping timeout: 260 seconds) 00.55.56 Join robertd1 [0] (~root@201.211.53.103) 00.56.10 # nm simplelist is the way to go so thats where ill start Thanks Saint 01.02.26 Part robertd1 01.04.12 # <__builtin_> can anyone help me track down a panic in pcm_play_data()? 01.08.42 Nick __builtin_ is now known as __builtin (~xray@unaffiliated/franklin) 01.09.38 # <__builtin> right now the trace shows that it calls a function and then somehow jumps to 0x20F4 01.09.44 Join robertd1 [0] (~root@201.211.53.103) 01.10.28 Part robertd1 01.11.01 # <__builtin> is there anything of interest in that memory region? 01.16.57 Quit ZincAlloy (Quit: Leaving.) 01.22.22 # <__builtin> hmm, I figured out what function that is, looks like it maps to the IRAM 01.22.49 # <__builtin> which raises another question: is it required that the audio callback or pcm buffer be in IRAM? 01.25.51 # <__builtin> prof_wolfff: you wrote the PL080 driver, right? 01.27.14 # <__builtin> can you help explain why it's panicking on target/arm/s5l8702/pl080.c:438? 01.30.30 Join robertd1 [0] (~root@201.211.53.103) 01.39.33 Join JanC_ [0] (~janc@lugwv/member/JanC) 01.40.17 Quit scorche (Read error: Connection reset by peer) 01.40.47 Quit JanC (Ping timeout: 260 seconds) 01.40.47 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 01.44.53 Join Bilgus0 [0] (4cf32773@gateway/web/freenode/ip.76.243.39.115) 01.46.25 Quit Bilgus0 (Client Quit) 01.48.39 Quit alexweissman (Remote host closed the connection) 01.51.12 Part robertd1 01.53.55 # __builtin: while PCM playback the next DMA transfers must be linked before the previous DMA transfer finished, otherwise it panics, usually this is because the CPU is processing some other long interrupt and the DMA interrupt must wait, if IIRC the buffer defined in pcm-s5l8702.c can store about 5ms for 48khz playback sample rate, so probably there is some interrupt that takes more than 5ms to complete 01.58.52 # you can try to increase the buffer size an see if the panic persists, i think it is PCM_WATERMARK in pcm-target.h 02.02.12 # <__builtin> so could it be that my get_more callback is too slow? 02.02.14 Quit girafe (Read error: Connection reset by peer) 02.04.39 # not necesary, it might be any other interrupt not related with playback or DMA, note that unboosted CPU an buses ares ~4 times slower 02.06.02 # <__builtin> it only happens when it runs my code though 02.07.19 # so there might be some problems on that code related with interrupts 02.07.54 # <__builtin> what restrictions do I have in an interrupt context? 02.09.36 # interrupts should be fast and be careful to not to block them using mutexes 02.10.01 # <__builtin> ohh that makes sense 02.10.16 # <__builtin> there's a mutex lock in a mixer function 02.10.29 # <__builtin> and besides, I was using splash() calls for logging :P 02.10.45 # <__builtin> so no wonder it was slow 02.13.55 # even serial debug inside interrupts can be slow if there is too much output, try to use the normal logf 02.14.46 # or the USB debug if you want 'realtime' debug 02.14.51 # <__builtin> and does it have to be in IRAM? 02.14.57 # <__builtin> (the callback) 02.17.12 # for the Classic it is not really necessary, really the first 128KB of IRAM is slower than DRAM, and the second 128KB are slighter faster 02.18.48 # <__builtin> ok, I still can't figure it out 02.19.00 # <__builtin> the callback has all extraneous code removed 02.19.22 # <__builtin> could it have to do with how many samples it's returning at once? 02.22.13 # what are you referring exactly, the dma_play_callback() ? 02.22.47 # <__builtin> the get_more() function pointer supplied to pcm_play_data() 02.24.41 Quit krnlyng (Ping timeout: 250 seconds) 02.25.57 # i cannot recall exactly how playback was working, but the get_more() is called inside the interrupt, so it must be fast 02.29.51 # <[Saint]> what're you actually working on __builtin? 02.30.15 # <[Saint]> is whatever it is you're seeing repeatable and not caused by your own modification(s)? 02.36.12 # <__builtin> xworld 02.36.30 # <__builtin> I'm trying to get sound to work, for the Nth time 02.36.42 # <[Saint]> Ah, right. 02.36.47 # <__builtin> I swear I fixed it before it got merged :S 02.36.52 # <__builtin> but apparently not 02.37.19 Join krnlyng [0] (~liar@178.112.157.21.wireless.dyn.drei.com) 02.38.13 # <__builtin> [Saint]: can you do me a favor and test a build? 02.38.24 # <__builtin> on another target, and see if it's specific to the classic 02.43.29 # if there are no bugs then the Classic should behave as the other targets, the DMA link is internal to the target and it is supposed that the RB API is respected, tell me if you see some incorrect behaviour 02.44.29 # <__builtin> yeah, so it's probable that xworld is incorrect 02.45.54 # i tested it with the plugins that are using playback i seems to work well for them 02.46.53 *** Saving seen data "./dancer.seen" 02.50.53 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 02.51.05 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 02.51.05 # * __builtin tries moving everything to DRAM 02.51.26 # <__builtin> YES!! 02.51.29 # <__builtin> it works :D 02.51.47 Quit Strife1989 (Read error: Connection reset by peer) 02.52.02 # <__builtin> but it crashes if I increase the "chunk" size, aka how many samples returned at a time 02.52.18 # <__builtin> which makes some sense given what prof_wolfff said 02.57.16 Join Strife89 [0] (~quassel@adsl-98-80-191-93.mcn.bellsouth.net) 02.59.14 Join alexweissman [0] (~alexweiss@2602:306:3893:2620:b12a:dad8:8732:31d0) 02.59.56 # IIRC if the received buffer size is huge then it is splited into small DMA transfers, not only for Classic but also for other targets, BUT the get_more() is called once for the whole buffer inside just one single interrupt so this callback must be fast enough to not to consume too much time for an interrupt 03.01.26 # <__builtin> yeah, that explains the crash now 03.01.42 # <__builtin> I need to figure out if other targets have similar bugs though 03.03.51 Quit alexweissman (Ping timeout: 260 seconds) 03.05.59 # many HW DMA engines cannot do large transfers, i think it is not a bug, it seems designed that way, if you want to use large buffer then the buffer should be processed in user space by the plugin and the get_more() should get pointers to that buffer but not to do extensive processing into get_more() 03.06.25 # <__builtin> yeah, that's what I was thinking 03.07.30 # <__builtin> but it would be rather complex to rewrite it to use synchronous mixing, so could I just limit the buffer size to <128 samples? 03.11.14 # for the classics it will work if the interrupt is < 5ms (too much time for an interrupt, even 1ms is too much time, but it will work), you can try the size that the normal playback is using in the hope it will work for the other targets 03.12.17 # <__builtin> yeah, it looks to me that the doom plugin defaults to 128 samples 03.12.23 # the Classic panics when the playback is broken, but other targets will cut the output 03.18.23 # <__builtin> hmm, does button_get artificially introduce a delay between when a button is first pressed and its repeat presses? 03.18.38 # <__builtin> it makes charging the weapon difficult in the game 03.23.24 # uff, cannot help on that, all the button stuff is magic for me 03.23.52 # <__builtin> thanks for your help prof_wolfff 03.25.04 # <__builtin> night 04.44.57 Quit krabador (Ping timeout: 260 seconds) 04.46.56 *** Saving seen data "./dancer.seen" 04.48.35 Join robertd1 [0] (~root@201.211.53.103) 04.57.21 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 05.12.18 Quit tchan (Quit: WeeChat 1.6) 05.25.59 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 05.30.46 Quit Bilgus (Quit: Page closed) 05.57.56 Quit alexweissman (Remote host closed the connection) 05.58.49 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 05.59.58 Quit robertd1 (Ping timeout: 268 seconds) 06.05.21 Join robertd1 [0] (~root@201.211.53.103) 06.20.53 Quit TheSeven (Ping timeout: 245 seconds) 06.21.30 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.47.00 *** Saving seen data "./dancer.seen" 06.48.00 Quit Bray90820 (Ping timeout: 250 seconds) 06.58.33 Quit amayer (Ping timeout: 268 seconds) 07.14.51 Quit robertd1 (Ping timeout: 260 seconds) 07.15.18 Join robertd1 [0] (~root@201.211.53.103) 07.31.39 Join ender` [0] (krneki@foo.eternallybored.org) 07.35.43 Quit [Saint] (Remote host closed the connection) 07.36.46 Join [Saint] [0] (~sinner@rockbox/staff/saint) 07.38.25 Join amayer [0] (~amayer@mail.weberadvertising.com) 07.50.15 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 07.50.15 Quit pixelma (Quit: .) 07.50.27 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 07.50.28 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 08.38.47 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 08.47.04 *** Saving seen data "./dancer.seen" 08.53.11 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 08.53.24 Quit robertd1 (Ping timeout: 260 seconds) 09.05.03 Join robertd1 [0] (~root@201.211.53.103) 09.12.41 Join wodz [0] (~wodz@94-75-75-29.home.aster.pl) 09.19.57 Quit robertd1 (Ping timeout: 252 seconds) 09.29.12 Quit pamaury (Ping timeout: 250 seconds) 09.32.09 Join robertd1 [0] (~root@201.208.225.40) 09.39.31 Quit robertd1 (Ping timeout: 260 seconds) 09.49.54 Join elensil [0] (~edhelas@2001:1c02:1903:d800:d031:9638:2808:63e5) 09.50.20 Join robertd1 [0] (~root@201.211.53.103) 09.54.11 Join Bray90820 [0] (~bray90820@50-83-212-56.client.mchsi.com) 09.59.56 Quit robertd1 (Ping timeout: 260 seconds) 10.02.09 Join robertd1 [0] (~root@201.211.53.103) 10.21.36 Quit robertd1 (Ping timeout: 256 seconds) 10.26.08 Join pamaury [0] (~quassel@wks-50-63.mpi-sws.org) 10.26.08 Quit pamaury (Changing host) 10.26.08 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.26.44 Join robertd1 [0] (~root@201.211.53.103) 10.28.07 Quit [Saint] (Remote host closed the connection) 10.29.09 Join [Saint] [0] (~sinner@rockbox/staff/saint) 10.36.58 Quit robertd1 (Ping timeout: 250 seconds) 10.37.24 Join robertd1 [0] (~root@201.211.53.103) 10.42.50 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 10.47.08 *** Saving seen data "./dancer.seen" 11.10.20 Quit [Saint] (Read error: Connection reset by peer) 11.12.01 Join [Saint] [0] (~sinner@rockbox/staff/saint) 11.35.15 Quit robertd1 (Ping timeout: 252 seconds) 11.35.30 # __builtin: I don't think button_get introduces a delay, but the input system is quite complicated. I can think of two things that influence timing: 1) tick task -> input is polled 'only' 100 times per second 2) debouncing -> some button driver (or even hardware) need to implement debouncing and that limits the rate at which you can detect two key presses 11.35.42 # I'll have a closer look at button_get just to be sure 11.37.20 Join robertd1 [0] (~root@201.211.53.103) 11.38.00 Part robertd1 11.42.36 Quit ruhans (Ping timeout: 260 seconds) 11.43.33 Quit Elfish (Ping timeout: 260 seconds) 11.43.33 Quit preglow (Ping timeout: 260 seconds) 11.44.01 Quit ender| (Ping timeout: 260 seconds) 11.44.01 Quit Staphylo (Ping timeout: 260 seconds) 11.44.01 Quit Slasheri (Ping timeout: 260 seconds) 11.44.18 Join Slasheri [0] (~miipekk@xen.ihme.org) 11.44.18 Quit Slasheri (Changing host) 11.44.18 Join Slasheri [0] (~miipekk@rockbox/developer/Slasheri) 11.44.28 Quit Rondom (Ping timeout: 260 seconds) 11.44.39 # __builtin: however remember that the input system has at least three ways of getting keys: button_get() that will block for an event unless you put false and return no key if no event, then there is button_get_w_tmo which is more advanced, and there is button_read(0 that gives you the raw input but doesn't dequeue events 11.45.30 Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) 11.45.37 Join ruhans [0] (uid76353@gateway/web/irccloud.com/x-dkrevjmgefztvlfw) 11.49.40 Quit rela (Read error: Connection reset by peer) 11.50.01 Join rela [0] (~x@pdpc/supporter/active/rela) 11.52.47 Join Elfish [0] (amba@84.201.30.174) 11.56.10 Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) 11.56.42 Join Staphylo [0] (~Staphylo@2a01:4f8:190:126a:d70a:378:c354:a3a3) 12.07.04 Quit atsampson (Ping timeout: 260 seconds) 12.10.22 # hi 12.10.55 # cc___: ask your question if you have one? 12.11.12 # is there a recommended way to display lyrics on rockbox ? or is using the text editor and text files the right approach ? 12.12.04 # I am not sure but I don't think we have a way to displaying lyrics, I might be wrong 12.13.00 Join atsampson [0] (~ats@cartman.offog.org) 12.13.21 # there was a patch for that a long time ago apparently: https://www.rockbox.org/tracker/task/7432 12.13.30 # but it probably doesn't compile 12.13.35 # * pamaury needs to leave 12.13.56 # pamaury: then is there a way to make the text viewer a bit more convenient ? when I press select to display the menu it also adds a bookmark 12.28.01 Join rela_ [0] (~x@p200300764D5D4F00BC18F7FF479CF2F7.dip0.t-ipconnect.de) 12.31.48 Quit rela (Ping timeout: 260 seconds) 12.44.02 Join preglow [0] (~thomj@2001:840:4243:3::101) 12.47.12 *** Saving seen data "./dancer.seen" 12.52.40 Quit rela_ (Read error: Connection reset by peer) 12.53.01 Join rela_ [0] (~x@p200300764D5D4F00BC18F7FF479CF2F7.dip0.t-ipconnect.de) 13.01.59 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217) 13.05.01 # pamaury: I was compiling a sim build last night #1412 was making it fail I put info on the tracker 13.09.35 Quit Bilgus (Quit: Page closed) 13.10.36 # cc___: if I remember correctly Rockbox can show lrc files but I don't know how and if it works conveniently (haven't used it myself yet even though I'm a bit curious) 13.12.30 # maybe look for "lrcplayer" in the plugins section of your target's manual 13.24.43 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:900e:32a9:642d:e122) 13.38.03 Join smoke_fumus [0] (~smoke_fum@leased-line-195-222-90-170.telecom.by) 13.40.06 Nick smoke_fumus is now known as ignus (~smoke_fum@leased-line-195-222-90-170.telecom.by) 13.40.23 Nick ignus is now known as smoke_fumus (~smoke_fum@leased-line-195-222-90-170.telecom.by) 14.05.09 Join Strife89|laptop [0] (~Strife89@2602:306:bce1:8c20:5a94:6bff:fe41:c78) 14.05.11 Nick Strife89|laptop is now known as Strife1989 (~Strife89@2602:306:bce1:8c20:5a94:6bff:fe41:c78) 14.05.35 Nick Strife1989 is now known as Strife89|Work (~Strife89@2602:306:bce1:8c20:5a94:6bff:fe41:c78) 14.08.25 Join paulk-minnie [0] (~paulk@no3.u-bordeaux.fr) 14.23.31 Quit rela_ (Quit: Leaving) 14.27.01 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 14.45.43 Quit pamaury_ (Ping timeout: 260 seconds) 14.47.13 *** Saving seen data "./dancer.seen" 15.09.45 Join krabador [0] (~krabador@unaffiliated/krabador) 15.17.31 Quit [Saint] (Read error: Connection reset by peer) 15.18.34 Join [Saint] [0] (~sinner@rockbox/staff/saint) 15.29.35 Join robertd11 [0] (~root@201.208.225.40) 15.29.46 Quit wodz (Ping timeout: 265 seconds) 15.29.55 Join ulmutul [0] (~chatzilla@x4d09a997.dyn.telefonica.de) 15.37.41 Quit [Saint] (Remote host closed the connection) 15.40.07 Quit Strife89|Work (Quit: Leaving) 15.54.32 # __builtin: afaik rockbox indeed introduce a delay. button_get() reads the event queue; the first button event is created immediately after pressing, and if you keep holding down the key, after REPEAT_START the button code sends more distinct events to the queue in accelerating tempo (they're only send, if the queue is empty, to avoid afterscroll effects). 15.55.13 # This is completely handled in button_tick() in button.c. For your purpose you have to use button_read() 16.05.38 # ulmutul: I wonder if his question was more about if you press a button twice very quickly ? 16.05.58 # or maybe not, his question was vague 16.06.25 # BTW I tested XWorld on my YH925 (PP5020 target), and the first time I started the intro, sound worked. I tried out different buffer settings, and settings of 128 samples and above made the player hang at some point. I tried the smaller settings, and I got no sound output at all. Even with 64 samples (which I believe is the standard) I have no output now. I will try you patch now and report... 16.06.26 # ...problems. 16.07.13 # pamaury: I never really played the game, so I don't know what buttons to press :) 16.08.24 # But yes, maybe I misunderstood. 16.08.36 # I never played either :) 16.11.59 # ah, he uses button_status() 16.12.52 Quit Jinx (Quit: reboot) 16.13.13 # so my explanation of how button_get() works was rather pointless :) 16.19.14 Quit krabador (Remote host closed the connection) 16.36.57 Quit robertd11 (Read error: Connection reset by peer) 16.37.04 Join robertd1 [0] (~root@201.208.225.40) 16.47.15 *** Saving seen data "./dancer.seen" 16.49.10 Join krabador [0] (~krabador@unaffiliated/krabador) 16.50.50 # Debouncing is done in button_read() and takes one additional tick for each state change (so one for the release, one for the next press). There may be additional delay for some targets by hardware-debouncing or in the target specific low level drivers. 16.55.34 Quit alexweissman (Remote host closed the connection) 16.56.08 Quit paulk-minnie (Quit: Leaving) 17.37.34 Join rela [0] (~x@pdpc/supporter/active/rela) 17.37.44 Quit ulmutul (Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]) 17.44.31 Join Strife1989 [0] (~Strife89@2602:306:bce1:8c20:5a94:6bff:fe41:c78) 17.51.49 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 17.52.03 Quit elensil (Quit: Leaving.) 17.57.27 Quit rela (Quit: Leaving) 18.06.20 Join alexweissman [0] (~alexweiss@2001-18e8-2-28cc-f000-51a.dhcp6-bl.indiana.edu) 18.11.03 Quit alexweissman (Ping timeout: 260 seconds) 18.15.14 Quit pamaury (Remote host closed the connection) 18.19.35 Quit bluebrother (Disconnected by services) 18.19.40 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 18.20.36 Join fs-bluebot [0] (~fs-bluebo@xd9bafcc6.dyn.telefonica.de) 18.21.33 Quit toli (Ping timeout: 256 seconds) 18.23.00 Quit fs-bluebot_ (Ping timeout: 260 seconds) 18.24.20 Quit dan- (Ping timeout: 248 seconds) 18.28.08 Join toli [0] (~toli@ip-62-235-196-174.dsl.scarlet.be) 18.34.37 Quit MrZeus (Read error: Connection reset by peer) 18.47.18 *** Saving seen data "./dancer.seen" 19.10.33 Quit ZincAlloy (Quit: Leaving.) 19.12.06 Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) 19.15.58 Quit WakiMiko_ (Max SendQ exceeded) 19.18.01 Join WakiMiko_ [0] (~WakiMiko@unaffiliated/wakimiko) 19.19.34 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 19.22.00 # * pamaury got a Fiio X3. Even more incentive to port rockbox to the X1 and X3 quickly 19.22.00 Quit prof_wolfff (Ping timeout: 252 seconds) 19.27.55 Quit munch (Excess Flood) 19.27.55 Quit WakiMiko_ (Max SendQ exceeded) 19.28.02 # congrats pamaury. I am trying to write the lua for the x5 http://pastebin.com/NMt1SVV4 but keep getting the Cannot load description file '../../regtools/desc//regs-atj213x.xml' 19.28.29 # robertd1: you can ignore this message 19.28.43 # if it doesn't print any other major error, it's working 19.29.00 Join WakiMiko_ [0] (~WakiMiko@unaffiliated/wakimiko) 19.29.06 # did it produce the fiio_x5_ipl.bin file? 19.30.01 # pamaury no it produces a Fatak unknown 'name' attribute 19.30.11 # robertd1: give me the full output 19.30.32 # the errors when loading register files ae not fatal 19.30.43 # the tool continues to run 19.31.01 # http://pastebin.com/xTdnRqas 19.31.27 Join munch [0] (pls@gateway/shell/elitebnc/x-heoyllcjhlvsacaq) 19.32.23 # it must be printing something else 19.32.56 # hi pamaury i found what's wrong i think 19.33.14 # nothing happens on internal memory, plays okay 19.33.20 # pamaury it freezes then I get an cannot open device but it is listed Ingenic Semiconductor 19.33.28 # but had those issues happening on memory card 19.33.40 Quit munch (Excess Flood) 19.33.40 # robertd1: please give me the full output, everything 19.33.56 # so what can i do? format the card and then copy music back to it? 19.34.22 # cryham: interesting, did you retest all versions I sent you using the memory card? 19.34.25 # http://pastebin.com/6paBLt4Y 19.34.28 Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) 19.34.50 # no just the previous 19.34.51 # robertd1: which gerrit patch are you using? 19.35.06 # but i think this is the cause 19.36.03 # the 69c773b9.diff 19.37.50 # robertd1: what is this? I didn't send you a diff, I'm sure of it 19.38.18 # ah that's the commit id, it's too old, this bug was fixe 19.38.19 # d 19.38.29 # you need to be at g#1411 19.38.30 # 3Gerrit review #1411 at http://gerrit.rockbox.org/r/1411 : 3hwstub: add Fiio X3II IPL/SPL dumping code by Amaury Pouly 19.39.05 # thanks pamaury let me try it :) 19.39.29 # cryham: give me some time and I will send you a build to test, you still confirm that it did not happen on the original 2013 build? 19.39.35 # (even on memory card) 19.39.43 # yes 19.40.27 # 2013 was ok, just booted a bit longer 19.40.27 Join munch` [0] (pls@gateway/shell/elitebnc/x-qcqpdbjfdpvoiaxo) 19.41.18 # ok, I have an idea, it doesn't quite explain why it would freeze but that's the only obvious difference between internal storage and mmc that comes to mind 19.46.47 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 19.53.04 Quit krabador (Quit: Leaving) 19.54.10 # pamaury http://pastebin.com/C6L66Fbx 19.55.46 Join rela [0] (~x@pdpc/supporter/active/rela) 19.56.05 # this is unexpected 19.56.29 # are you sure HEAD is at 4366ea5a831d5d69699a4aaf3100208329eb754b without modifications? 19.57.43 # pamaury yes, let me repeat the procedure and make clean 20.14.10 Join stickyb1t [0] (~egon@avondaleaber.plus.com) 20.21.24 Quit rela (Read error: Connection reset by peer) 20.21.45 Join rela [0] (~x@pdpc/supporter/active/rela) 20.29.54 Quit rela (Read error: Connection reset by peer) 20.30.36 Join rela [0] (~x@pdpc/supporter/active/rela) 20.35.20 Quit bzed (Quit: leaving) 20.39.10 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:c599:9d0:aaee:fe13) 20.46.24 Join JanC_ [0] (~janc@lugwv/member/JanC) 20.47.13 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 20.47.22 *** Saving seen data "./dancer.seen" 20.47.39 Nick JanC is now known as Guest51811 (~janc@lugwv/member/JanC) 20.47.39 Quit Guest51811 (Killed (weber.freenode.net (Nickname regained by services))) 20.47.39 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 20.51.15 Join girafe [0] (~girafe@LFbn-1-8015-136.w90-112.abo.wanadoo.fr) 21.06.22 Join bzed [0] (~bzed@shell.bzed.at) 21.25.45 Join girafe2 [0] (~girafe@LFbn-1-8015-136.w90-112.abo.wanadoo.fr) 21.27.48 Quit girafe (Ping timeout: 260 seconds) 21.43.15 Quit munch` (Quit: Let's blast this shit and get naked) 21.44.23 Join ParkerR_ [0] (ParkerR@znc.withg.org) 21.44.57 Join munch [0] (pls@gateway/shell/elitebnc/x-gofslgdbevfaupvo) 21.48.32 Quit ParkerR (Ping timeout: 250 seconds) 21.52.11 Quit Guest7162 (Ping timeout: 244 seconds) 21.53.27 Join Guest7162 [0] (~Slayer@c-68-33-117-184.hsd1.va.comcast.net) 22.00.06 Quit Strife1989 (Quit: Leaving) 22.14.31 Quit amayer (Quit: Leaving) 22.44.04 Join krabador [0] (~krabador@unaffiliated/krabador) 22.47.25 *** Saving seen data "./dancer.seen" 23.15.35 Join JanC_ [0] (~janc@lugwv/member/JanC) 23.16.50 Quit JanC (Killed (tepper.freenode.net (Nickname regained by services))) 23.16.50 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC)