--- Log for 11.02.117 Server: adams.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 7 days and 5 hours ago 00.03.59 Quit scorche (Read error: Connection reset by peer) 00.08.05 # I remember where I know that name from now. It used to be used as an identifier in the Lua of Minetest, though I don't think that it is any more. 00.13.02 Join scorche [0] (~scorche@rockbox/administrator/scorche) 00.34.52 # __builtin: it looks okay now. thanks 00.42.55 Quit skapazzo (Quit: leaving) 00.51.01 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) 00.58.23 Quit Moarc (Ping timeout: 258 seconds) 00.58.57 Join Moarc [0] (~chujko@a105.net128.okay.pl) 01.00.07 *** Saving seen data "./dancer.seen" 01.09.12 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 01.12.54 Quit Bray90820 (Remote host closed the connection) 01.27.16 Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com) 01.38.12 # JhMikeS is your 1556 patch ready to go? 01.42.10 Quit ender` (Quit: The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. — Bertrand Russell) 01.43.39 # do I just call root_unmount_volume( and unmount drive 0 and then root_mount_path( with my new path? 01.54.05 # Bilgus: regarding the second thing: wot? 01.55.29 # regarding the first thing: 1) needs to be cut back for targets that don't need to mount various directories 2) The sim needs to be worked on 01.56.02 # ok so i'll give you a for instance I just booted My bootdata indicates volume 1 is boot drv and I have a redirect to /<1>/test/.rockbox what do I need to do? 01.56.04 # Bilgus: why do you need to unmount anything first? that sounds weird 01.56.54 # Oh I assumed you had to unmount before you added your new one then re-enumerate 01.56.57 # if you want to switch mounts, then unmount the root and mount something else there 01.57.12 # you do, yes 01.59.08 # but yeah, if you unmount the volume that also has the root it gets that too 02.00.30 # gets what too? 02.00.35 # I didn't make it so you can just unmount the root itself but that wouldn't be much trouble actually 02.01.43 # Bilgus: if the volume you unmount happens to be the one that contains the mounted root directory, it unmounts the root too 02.02.39 # ok so as far as all the streams and file functions what Do i need to do to 'emulate' <1>/test.rockbox as the main directory, atm in this scenario it will write to <0>/.rockbox 02.03.34 # <0> is always volume 0 02.03.40 # I don't necessarily want to unmount the true root 02.05.26 # that would be <1>/test/.rockbox 02.06.21 # thus "/foo" really accesses "/<1>/test/.rockbox/foo" 02.07.27 # ok so I would mount <1>/test and /.rockbox would actually be '<1>/test.rockbox' 02.07.59 # ok so I would mount <1>/test and /.rockbox would actually be '<1>/test/rockbox' 02.08.14 # .rockbox' grr 02.08.19 # heh 02.08.30 # yes 02.10.21 # ok so All I need to do then is pass root_mount_path() my new path and flags? 02.11.38 # really, those should not be called directly. disk_mount_all are supposed to call that stuff 02.13.04 # if you change the macro to point to a string that returns the correct path, it should get done at firmware boot 02.14.36 # ah ok so RB_ROOT_CONTENTS needs to mount to my <1>/test directory? 02.14.45 # sorry point* 02.15.14 # yes 02.16.26 # it doesn't have to be entirely static at compile time as long as a path is contructed before disk_mount_all is called during init 02.16.47 # and what do I do with RB_ROOT_VOL_HIDDEN(v) in this scenario pass 0? 02.17.32 # replace that macro if there are volumes you don't want showing up in the browser. it should return true for any v you don't want to see 02.17.59 # right now it just defaults to hiding 0, since that's how it is for most 02.20.12 # ok I think I have it I'll try it out tomorrow Thanks. 02.43.34 Quit mutnai (Quit: Page closed) 03.00.09 *** Saving seen data "./dancer.seen" 03.00.24 # Build Server message: 3New build round started. Revision 6436c6e, 255 builds, 17 clients. 03.11.01 Quit ZincAlloy (Quit: Leaving.) 03.11.22 # Build Server message: 3Build round completed after 657 seconds. 03.11.23 # Build Server message: 3Revision 6436c6e result: All green 03.23.05 # <__builtin> does anyone know why ARM doesn't print a backtrace on a panic? 03.23.36 # it's supposed to (bt:), sometimes it works 03.26.53 # nvm, not panic :) 03.31.37 # <__builtin> huh, so it's not intentionally disabled or anything 03.42.47 Quit Bray90820 (Read error: Connection reset by peer) 03.43.25 Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com) 03.47.08 Quit Amboyna (Ping timeout: 264 seconds) 03.50.43 Join TorC [0] (~TorC@fsf/member/TorC) 04.18.04 Quit Moarc (Ping timeout: 240 seconds) 04.19.13 Join Moarc [0] (~chujko@a105.net128.okay.pl) 05.00.13 *** Saving seen data "./dancer.seen" 05.43.27 Quit alexweissman (Remote host closed the connection) 05.44.42 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 06.53.07 Quit alexweissman (Remote host closed the connection) 06.53.47 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 06.58.39 Quit TheSeven (Ping timeout: 245 seconds) 06.59.08 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 07.00.07 Quit furrywolf (Ping timeout: 252 seconds) 07.00.17 *** Saving seen data "./dancer.seen" 07.19.49 Quit advcomp2019__ (Ping timeout: 258 seconds) 07.20.36 Join advcomp2019 [0] (~advcomp20@65-131-154-48.sxct.qwest.net) 07.20.36 Quit advcomp2019 (Changing host) 07.20.36 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 07.29.31 Quit pixelma (Quit: .) 07.29.32 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 07.32.54 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 07.32.55 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 07.59.24 # * dys found another aspect where the cf->sdcard adapter ignores the spec 08.00.23 # removing supply power makes it turn 150mW into heat through its data pins 08.00.31 # * dys needs to patch ata.c even more 08.18.32 Quit bluebrother (Ping timeout: 240 seconds) 08.18.58 Quit fs-bluebot (Ping timeout: 255 seconds) 08.20.31 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 08.33.07 Join fs-bluebot [0] (~fs-bluebo@xd9bafb59.dyn.telefonica.de) 08.37.23 Quit PurlingNayuki (Ping timeout: 245 seconds) 09.00.21 *** Saving seen data "./dancer.seen" 09.34.02 Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) 09.42.09 # Bilgus: The Rocker turned off due to low battery a bit sooner as I expected. I was sleeping. It stopped at the 130th song. According to MP3tag, that's 9,5 hours 09.43.02 # sooner than* 10.52.14 Join ender` [0] (krneki@foo.eternallybored.org) 11.00.22 *** No seen item changed, no save performed. 11.31.37 Quit JanC (Ping timeout: 276 seconds) 11.33.37 Join JanC [0] (~janc@lugwv/member/JanC) 12.16.33 Join krabador [0] (~krabador@unaffiliated/krabador) 12.16.40 Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) 12.43.04 Join StaticAmbience [0] (~Quassel@host213-1-11-77.range213-1.btcentralplus.com) 13.00.26 *** Saving seen data "./dancer.seen" 13.07.40 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:e447:1a5c:787c:e470) 13.13.48 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 13.23.34 Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) 13.49.28 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 13.51.27 Quit jhMikeS (Ping timeout: 240 seconds) 13.56.30 Quit paulk-collins (Remote host closed the connection) 13.58.04 Quit pamaury (Ping timeout: 260 seconds) 14.12.57 # gah, gone again 14.13.13 # * dys wonders whether pamaury has an idea how to deal with the C++ vtables 14.14.10 # always when the disassembly is about to get interesting, the calls are obscured 14.20.35 # you gotta make a struct to match vtable and change pointer type to that 14.20.54 # a real cunt to do, too , since struct editing in ida is retarded af 14.24.10 # thats not that bad was that with the screen on buttons unlocked? 14.46.40 # Bilgus: display off (on for about 2 min overall), low gain, volume 20/60 with IEM loaded, mostly MP3 VBR V0 and CBR 192 and a few FLAC and MP3 CBR 128 and WMA CBR 128 14.48.16 # ah so thats about best case overall does it seem to have a large file buffer or do you think thats with a lot of sd accesses? 14.49.30 # I thought AGPTek meant 10hrs with lossless files and 15hrs with MP3 files 14.49.59 # I'm currently running the benchmark again to see if the battery is better calibrated now 14.50.24 # I don't know about the buffer. 14.51.27 # but gapless playback doesn't work if you go to the 15 last seconds of the current song and wait for the next song 14.51.33 # while it works in Rockbox 14.52.39 # I need to play the whole current song so that next one loads without gap inbetween 15.00.30 *** Saving seen data "./dancer.seen" 15.05.08 # ah so probably just a lot of sd access 15.08.47 # It has a 600mAh battery 15.09.13 # even if the CPU is quite powerful, I'm surprised I don't reach more than 10 hrs with mostly MP3 files 15.09.41 # I hope it's a lack of optimization and that it could be better in Rockbox 15.15.40 # I'm sure there is still some wiggle room in there but honestly I don't typically listen to my DAP much more than 8 hrs in a day 15.16.26 # I neither for sure. But I don't want to charge it everyday 15.16.30 # it's not a smartphone! 15.16.58 # LOL I have a dumb phone thats one of the reasons its batt lasts 3-5 days 15.17.44 # I'm pretty used to charging my DAP daily 15.18.07 # though it is nice that if I forget it still has a days worth 15.18.26 Quit cc___ (Ping timeout: 256 seconds) 15.19.12 # thats like in the bad old days realizing your batteries were flat in your cd player and spinning the disk to make it so it wouldn't do low batt shutoff LOL 15.26.07 Quit dfkt (Quit: SIC GORGIAMVS ALLOS SVBJECTATOS NVNC.) 15.31.43 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 15.33.21 Quit cc___ (Client Quit) 15.33.57 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 16.17.54 Join paulk-aldrin [0] (~paulk@armstrong.paulk.fr) 16.23.46 Join furrywolf [0] (~randyg@m860536d0.tmodns.net) 16.30.39 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 16.38.45 Quit foo|sh (Remote host closed the connection) 16.41.26 Join foolsh [0] (~starchase@162-204-199-234.lightspeed.sbndin.sbcglobal.net) 16.41.52 Quit foolsh (K-Lined) 16.42.31 # pamaury: did you get the authorization to share the firmware and tools for the Rocker? 16.44.02 # lebellium: no, they don't want me to publish stuff. I wanted to send a message asking him to do a public firmware release so that everyone can have it but I was unlucky and couldn't reach the forum 16.44.53 # He pointed to the kernel and uboot source code though, those are public and on ingenic website so I guess that's fine. But since I can't reach the forums... 16.45.49 # dys: C++ is always a pain to RE. You have to create a structure for the vtable and identify the offset within the table for each function call, it makes tracing much harder. I usually come up with naming convention to make it easier 16.46.18 # it's already super annoyin with like IDA so I can't imagine doing it by hand 16.46.22 # pamaury: he replied on the forum that he would take my improved translation so I expect them to release a new firmware sooner or later anyway 16.47.16 # lebellium: ok, then almost all the binaries ar in the firmware upgrade, afaict it's just an iso with several files in it. The only extra I have is a tool to write the flash over usb I think, in Chinese 16.47.27 # with almost no doc 16.48.12 # Yes, they want you to put the fw on the sdcard and select the "upgrade firmware" setting 16.48.28 # they don't want the normal user to use a flashing tool 16.48.57 # yes, that's the sane way of processing. But the thing is that I have no info on the firmware upgrade process, I only have the firmware file and I can only guess how the process works 16.49.06 # <__builtin> pamaury: the forums seem to work now 16.50.10 # actually the link to the source code of the kernel is http://www.ingenic.com/en/?newsshow/tp/228/id/113.html 16.50.22 # which is just the standard ingenic page explaining to get the git repo 16.50.35 # I assume you'll gathering all those links on the wiki page? 16.50.52 # gather* 16.51.59 # I am travelling and super busy until friday, I don't have the time right now 16.57.44 # and there is only one link so far, it's the ingenic one above :-p 16.58.27 # I mean also the programing manual and all the stuff 17.00.32 *** Saving seen data "./dancer.seen" 17.01.08 # I'll upoad the PM that I found on the ingenic website. As for the other stuff, it's useless. The bluetooth core "datasheet" I got is 2 pages long, only marketing bullshit 17.01.48 # ok 17.03.48 # the datasheet for the codec is availale on cirrus website: https://d3uzseaevmutz1.cloudfront.net/pubs/proDatasheet/CS42L51_F2.pdf 17.03.56 # https://www.cirrus.com/products/cs42l51/ 17.10.58 # * __builtin just found a horrendous bug in xworld 17.29.09 Join skapazzo [0] (~skapazzo@151.9.205.1) 17.48.09 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 19.00.36 *** No seen item changed, no save performed. 19.46.14 Quit pixelma (Quit: No Ping reply in 120 seconds.) 19.47.33 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 20.09.12 # pamaury: can you add me as a contributor to the repo onkyo_teac_tools? 20.09.31 # i found the code that does things with the header before the first boot block 20.12.12 Quit WakiMiko (Quit: WeeChat 1.8-dev) 20.13.47 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 20.20.48 # dys: what is your email address/github account ? 20.21.30 # anse1 (the only watcher of the project :-) 20.22.47 # dys: you should have received an invitation now 20.23.27 # thanks! 20.24.07 # what do the bytes before the header encode ? 20.24.15 # and what about the checksum at the end ? 20.25.35 # most of them are trivial info (version, build, date, time) 20.26.12 # i'm still chewing on the checksum 20.30.57 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) 20.34.44 # dys: feel free to update the repo with what you have already 20.35.33 # as you might have seen, I usually have the tool print info about all fields when the debug switch is enabled 20.35.51 # could be cool if you add debug output similarly for those other fields 20.36.23 # I found some inconsistencies when running on different update images… 20.36.36 # don't want to push things that obviously need a fixup… 20.36.48 # ok 21.00.06 Quit robertd1 (Ping timeout: 240 seconds) 21.00.38 *** Saving seen data "./dancer.seen" 21.05.15 Quit StaticAmbience (Quit: No Ping reply in 180 seconds.) 21.14.23 Quit mutnai (Ping timeout: 260 seconds) 21.14.53 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 21.19.40 Quit paulk-aldrin (Quit: Leaving) 21.19.41 Join StaticAmbience [0] (~Quassel@host213-1-11-77.range213-1.btcentralplus.com) 21.20.24 Quit jhMikeS () 21.20.59 Join AxelK [0] (~AxelK@p5790E9D9.dip0.t-ipconnect.de) 21.21.48 # Hi there. 21.22.31 # I would like to report a strange behavior with rockbox on my Sansa ClipZip when playing certain opus files. 21.22.58 # It lokks like a corner case to me and it is also not 100% reproducible. 21.23.19 Quit WakiMiko (Quit: WeeChat 1.8-dev) 21.23.36 # The only thing that seems to make the error more likely to appear is the bit rate used for encoding of the opus file. 21.23.52 # The lower the bit rate, the more likely the problem appears. 21.23.55 Quit StaticAmbience (Client Quit) 21.24.29 # Files with 32Kbit seem to give a good "chance" of getting hit by the problem. 21.24.50 # with 64Kbit the problem is at least very rare 21.25.19 # You start playing one of those files and within a short time (few seconds) you hit fast forward 21.25.20 Join StaticAmbience [0] (~Quassel@host213-1-11-77.range213-1.btcentralplus.com) 21.25.52 # The system might crash wit the need of a hard reset (pressingpower button for ca. 20 sec) 21.26.02 # Error message on the screen reads 21.26.08 # *PANIC* 21.26.14 # Stkov codec 21.26.30 # pc: 3006CAFAC sp:3 21.26.40 # correction 21.26.51 # pc: 3006CFAC sp:3 21.27.03 # A: 30098158 21.27.06 # bte end 21.27.09 # bt end 21.27.30 # Another instance this crash might happen though a lot less often 21.27.36 # you listen to a opus file 21.27.45 # you turn off the CliZip 21.28.06 # you turn it on again some time later and try to resume 21.28.35 # so the respective file should be played from where you left (or a few seconds before that point) 21.29.14 # sometimes the player crashes with the same message (OK, not shure if it is the excat same hex numbers) 21.29.48 # but the *PANIC* Stkov codec and bt end are being shown on the screen after the crash 21.30.39 # As said before, the second error is much more harder to reproduce than the one where you use fast forward directly after starting to play an opus file 21.31.40 # The problem does not appear when letting the file play for some time, 30 seconds to 1 minute seem to be enough and then hitting fast forward 21.32.33 # so maybe some information about the length of the file or some indexing information might not be fuly available and if so the crash appears 21.32.56 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 21.34.00 # I tried opus files encoded with "opusenc" (from opus-tools package) and with ffmpeg and the "-acodec libopus" option, same result 21.35.17 # Maybe some developer will read this later and in any case it is now in present in the archive at https://www.rockbox.org/irc/ (or at least it will be there soon) 21.35.20 # bye 21.35.23 Quit AxelK (Quit: Verlassend / Leaving) 21.36.19 Part Yst ("") 21.48.02 Join AxelK [0] (~AxelK@p5790E9D9.dip0.t-ipconnect.de) 21.48.23 # Sorry, forgot some important information. 21.50.13 # I am running the development branch of rockbox, atm release a4dc244 from february 10th 2017, so it is not a problem of an old release 21.51.00 # I have two ClipZip players, a 4GB and a 8GB model, both are affected 21.52.08 Quit AxelK (Client Quit) 21.52.22 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 21.58.32 Join qorx [0] (57673c1f@gateway/web/freenode/ip.87.103.60.31) 22.00.11 Quit WakiMiko (Quit: WeeChat 1.8-dev) 22.01.26 Quit pamaury (Ping timeout: 240 seconds) 22.01.59 # Hi, my clip+ all of a sudden messed up the sound.. It sounds like hearing music through a tin can, very metalic noise and no bass whatsoever 22.02.30 # It gets marginally better if I tweak the balance in the settings either way 22.02.50 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 22.03.01 Quit WakiMiko (Client Quit) 22.03.14 # If I leave it a 0, it's bad and can't hear decently 22.04.20 # I've never heard of this issue with clip+'s, does anyone know anything about that? 22.05.10 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 22.11.10 Quit WakiMiko (Quit: WeeChat 1.8-dev) 22.11.25 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 22.11.41 Quit amiconn (Quit: No Ping reply in 64 seconds.) 22.13.00 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 22.15.53 Join saratoga [0] (c036de1c@gateway/web/freenode/ip.192.54.222.28) 22.15.54 # qorx: the ground pin on your headphone jack isn't making contact, so you're hearing the L-R signal 22.17.55 # AxelK: if you can find a way to reproduce the problem, file a bug report with the instructions and a link to the file in question 22.39.33 Quit qorx (Ping timeout: 260 seconds) 22.49.39 Quit saratoga (Quit: Page closed) 22.50.52 Join qorx [0] (57673c1f@gateway/web/freenode/ip.87.103.60.31) 22.52.59 # saratoga: Thanks! That was it, I tested it just now and the sound is normal again upon proper contact. I'll fix properly, many thanks. 22.57.21 Join AxelK [0] (~AxelK@p5790E9D9.dip0.t-ipconnect.de) 22.57.38 Quit qorx (Ping timeout: 260 seconds) 22.59.31 # saratoga: that might e a bit of a problem, the files where it is somehow reproducible are self encoded opus files with 48 or 32 Kbit 23.00.39 *** Saving seen data "./dancer.seen" 23.00.41 # Most of the podcasts in opus format (at least the ones I listen to) use 64KBit and they are very rarely affected 23.02.17 # Another detail that might be important, the files seem to need a certain minimal length, short files of a few seconds or minutes seem to be fine, while podcasts of 1 or 2 hours are more likely to cause the problem 23.03.15 # As I tried to indicate before, it is a rather rare problem and I tried to avoid the word "bug" because it is not really easy to reproduce 23.04.17 Join Quantum1337 [0] (~Quantum13@unaffiliated/n00b81) 23.04.27 # the "best" shot might be to encode some opus file of 1 hour or longer (some podcast) with 32Kbit and try to get hit by that problem playing that file 23.05.17 # meaning, start playing it and quickly after that (i.e. as quickly as possible) try to fast forward 23.06.14 # also the amount of minutes trying to fast forward seems to be a factor, the further you try to get (10 minutes or more), the more likely the player will crash 23.08.39 Quit krabador (Ping timeout: 240 seconds) 23.09.23 # The only thing that makes me think it i not a problem with my encoding software is, that there the problem also apperas with 64Kbit opus files I did not encode myself (although very rarely) 23.10.42 Part Quantum1337 ("Leaving") 23.10.53 # and that files produced by two different encoding programs (at least slightly different as they use the same library) show this problem 23.13.34 # So for anyone tryingto reproduce this, take some longer audio file (podcast of 1 or two hours) let's say as an mp3 and run 23.14.05 # ffmpeg -i the.mp3 -c:a libopus -b:a 32k testfile.opus 23.14.16 # and try that file 23.15.02 # or if you want to use a file directly encoded with opusenc (which will also use libopus) 23.15.13 # get some longer wav file and encode with 23.15.41 # opusenc --bitrate 32k some.wav test.opus 23.18.13 # The version of libopus also does not seem to make a difference, I have files encoded with libopus 1.0.x up to those encoded with 1.1.4 (latest stable release) 23.19.49 # meaning I stumbled upon this (rare) problem quite some time ago, but I did not bother too much as it was more or less difficult to reproduce 23.22.11 # But now I think I have found at least some more details how to make it more likely to trigger this problem 23.22.57 # although it is still not an easy "here's how to crash your ClipZip in five easy steps" 23.48.03 Quit AxelK (Quit: Verlassend / Leaving) 23.49.04 Join AxelK [0] (~AxelK@p5790E9D9.dip0.t-ipconnect.de)