| 00:03:59 | | Quit scorche (Read error: Connection reset by peer) |
| 00:08:05 | Yst | 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 | jhMikeS | __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 |
| 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 | Bilgus | 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 | Bilgus | do I just call root_unmount_volume( and unmount drive 0 and then root_mount_path( with my new path? |
| 01:54:05 | jhMikeS | Bilgus: regarding the second thing: wot? |
| 01:55:29 | jhMikeS | 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 | Bilgus | 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 | jhMikeS | Bilgus: why do you need to unmount anything first? that sounds weird |
| 01:56:54 | Bilgus | Oh I assumed you had to unmount before you added your new one then re-enumerate |
| 01:56:57 | jhMikeS | if you want to switch mounts, then unmount the root and mount something else there |
| 01:57:12 | jhMikeS | you do, yes |
| 01:59:08 | jhMikeS | but yeah, if you unmount the volume that also has the root it gets that too |
| 02:00 |
| 02:00:30 | Bilgus | gets what too? |
| 02:00:35 | jhMikeS | I didn't make it so you can just unmount the root itself but that wouldn't be much trouble actually |
| 02:01:43 | jhMikeS | 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 | Bilgus | 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 | jhMikeS | <0> is always volume 0 |
| 02:03:40 | Bilgus | I don't necessarily want to unmount the true root |
| 02:05:26 | Bilgus | <Allow mounting of any directory as the root directory.> that would be <1>/test/.rockbox |
| 02:06:21 | jhMikeS | thus "/foo" really accesses "/<1>/test/.rockbox/foo" |
| 02:07:27 | Bilgus | ok so I would mount <1>/test and /.rockbox would actually be '<1>/test.rockbox' |
| 02:07:59 | Bilgus | ok so I would mount <1>/test and /.rockbox would actually be '<1>/test/rockbox' |
| 02:08:14 | Bilgus | .rockbox' grr |
| 02:08:19 | jhMikeS | heh |
| 02:08:30 | jhMikeS | yes |
| 02:10:21 | Bilgus | ok so All I need to do then is pass root_mount_path() my new path and flags? |
| 02:11:38 | jhMikeS | really, those should not be called directly. disk_mount_all are supposed to call that stuff |
| 02:13:04 | jhMikeS | 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 | Bilgus | ah ok so RB_ROOT_CONTENTS needs to mount to my <1>/test directory? |
| 02:14:45 | Bilgus | sorry point* |
| 02:15:14 | jhMikeS | yes |
| 02:16:26 | jhMikeS | 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 | Bilgus | and what do I do with RB_ROOT_VOL_HIDDEN(v) in this scenario pass 0? |
| 02:17:32 | jhMikeS | 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 | jhMikeS | right now it just defaults to hiding 0, since that's how it is for most |
| 02:20:12 | Bilgus | ok I think I have it I'll try it out tomorrow Thanks. |
| 02:43:34 | | Quit mutnai (Quit: Page closed) |
| 03:00 |
| 03:00:09 | *** | Saving seen data "./dancer.seen" |
| 03:00:24 | fs-bluebot | Build Server message: New build round started. Revision 6436c6e, 255 builds, 17 clients. |
| 03:11:01 | | Quit ZincAlloy (Quit: Leaving.) |
| 03:11:22 | fs-bluebot | Build Server message: Build round completed after 657 seconds. |
| 03:11:23 | fs-bluebot | Build Server message: Revision 6436c6e result: All green |
| 03:23:05 | __builtin | does anyone know why ARM doesn't print a backtrace on a panic? |
| 03:23:36 | jhMikeS | it's supposed to (bt:), sometimes it works |
| 03:26:53 | jhMikeS | 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:00 |
| 04:18:04 | | Quit Moarc (Ping timeout: 240 seconds) |
| 04:19:13 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 05:00 |
| 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:00 |
| 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: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 |
| 08:00:23 | dys | 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 |
| 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 | lebellium | 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 | lebellium | sooner than* |
| 10:00 |
| 10:52:14 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 11:00 |
| 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:00 |
| 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 |
| 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:00 |
| 14:12:57 | dys | gah, gone again |
| 14:13:13 | * | dys wonders whether pamaury has an idea how to deal with the C++ vtables |
| 14:14:10 | dys | always when the disassembly is about to get interesting, the calls are obscured |
| 14:20:35 | dongs | you gotta make a struct to match vtable and change pointer type to that |
| 14:20:54 | dongs | a real cunt to do, too , since struct editing in ida is retarded af |
| 14:24:10 | Bilgus | <lebellium> thats not that bad was that with the screen on buttons unlocked? |
| 14:46:40 | lebellium | 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 | Bilgus | 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 | lebellium | I thought AGPTek meant 10hrs with lossless files and 15hrs with MP3 files |
| 14:49:59 | lebellium | I'm currently running the benchmark again to see if the battery is better calibrated now |
| 14:50:24 | lebellium | I don't know about the buffer. |
| 14:51:27 | lebellium | 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 | lebellium | while it works in Rockbox |
| 14:52:39 | lebellium | I need to play the whole current song so that next one loads without gap inbetween |
| 15:00 |
| 15:00:30 | *** | Saving seen data "./dancer.seen" |
| 15:05:08 | Bilgus | ah so probably just a lot of sd access |
| 15:08:47 | lebellium | It has a 600mAh battery |
| 15:09:13 | lebellium | 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 | lebellium | I hope it's a lack of optimization and that it could be better in Rockbox |
| 15:15:40 | Bilgus | 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 | lebellium | I neither for sure. But I don't want to charge it everyday |
| 15:16:30 | lebellium | it's not a smartphone! |
| 15:16:58 | Bilgus | LOL I have a dumb phone thats one of the reasons its batt lasts 3-5 days |
| 15:17:44 | Bilgus | I'm pretty used to charging my DAP daily |
| 15:18:07 | Bilgus | 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 | Bilgus | 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:00 |
| 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 | lebellium | pamaury: did you get the authorization to share the firmware and tools for the Rocker? |
| 16:44:02 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | it's already super annoyin with like IDA so I can't imagine doing it by hand |
| 16:46:22 | lebellium | 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 | pamaury | 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 | pamaury | with almost no doc |
| 16:48:12 | lebellium | Yes, they want you to put the fw on the sdcard and select the "upgrade firmware" setting |
| 16:48:28 | lebellium | they don't want the normal user to use a flashing tool |
| 16:48:57 | pamaury | 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 | pamaury | 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 | pamaury | which is just the standard ingenic page explaining to get the git repo |
| 16:50:35 | lebellium | I assume you'll gathering all those links on the wiki page? |
| 16:50:52 | lebellium | gather* |
| 16:51:59 | pamaury | I am travelling and super busy until friday, I don't have the time right now |
| 16:57:44 | pamaury | and there is only one link so far, it's the ingenic one above :-p |
| 16:58:27 | lebellium | I mean also the programing manual and all the stuff |
| 17:00 |
| 17:00:32 | *** | Saving seen data "./dancer.seen" |
| 17:01:08 | pamaury | 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 | lebellium | ok |
| 17:03:48 | pamaury | the datasheet for the codec is availale on cirrus website: https://d3uzseaevmutz1.cloudfront.net/pubs/proDatasheet/CS42L51_F2.pdf |
| 17:03:56 | pamaury | 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 |
| 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:00 |
| 20:09:12 | dys | pamaury: can you add me as a contributor to the repo onkyo_teac_tools? |
| 20:09:31 | dys | 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 | pamaury | dys: what is your email address/github account ? |
| 20:21:30 | dys | anse1 (the only watcher of the project :-) |
| 20:22:47 | pamaury | dys: you should have received an invitation now |
| 20:23:27 | dys | thanks! |
| 20:24:07 | pamaury | what do the bytes before the header encode ? |
| 20:24:15 | pamaury | and what about the checksum at the end ? |
| 20:25:35 | dys | most of them are trivial info (version, build, date, time) |
| 20:26:12 | dys | 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 | pamaury | dys: feel free to update the repo with what you have already |
| 20:35:33 | pamaury | as you might have seen, I usually have the tool print info about all fields when the debug switch is enabled |
| 20:35:51 | pamaury | could be cool if you add debug output similarly for those other fields |
| 20:36:23 | dys | I found some inconsistencies when running on different update images… |
| 20:36:36 | dys | don't want to push things that obviously need a fixup… |
| 20:36:48 | pamaury | ok |
| 21:00 |
| 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 | AxelK | Hi there. |
| 21:22:31 | AxelK | I would like to report a strange behavior with rockbox on my Sansa ClipZip when playing certain opus files. |
| 21:22:58 | AxelK | 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 | AxelK | 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 | AxelK | The lower the bit rate, the more likely the problem appears. |
| 21:23:55 | | Quit StaticAmbience (Client Quit) |
| 21:24:29 | AxelK | Files with 32Kbit seem to give a good "chance" of getting hit by the problem. |
| 21:24:50 | AxelK | with 64Kbit the problem is at least very rare |
| 21:25:19 | AxelK | 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 | AxelK | The system might crash wit the need of a hard reset (pressingpower button for ca. 20 sec) |
| 21:26:02 | AxelK | Error message on the screen reads |
| 21:26:08 | AxelK | *PANIC* |
| 21:26:14 | AxelK | Stkov codec |
| 21:26:30 | AxelK | pc: 3006CAFAC sp:3 |
| 21:26:40 | AxelK | correction |
| 21:26:51 | AxelK | pc: 3006CFAC sp:3 |
| 21:27:03 | AxelK | A: 30098158 |
| 21:27:06 | AxelK | bte end |
| 21:27:09 | AxelK | bt end |
| 21:27:30 | AxelK | Another instance this crash might happen though a lot less often |
| 21:27:36 | AxelK | you listen to a opus file |
| 21:27:45 | AxelK | you turn off the CliZip |
| 21:28:06 | AxelK | you turn it on again some time later and try to resume |
| 21:28:35 | AxelK | so the respective file should be played from where you left (or a few seconds before that point) |
| 21:29:14 | AxelK | sometimes the player crashes with the same message (OK, not shure if it is the excat same hex numbers) |
| 21:29:48 | AxelK | but the *PANIC* Stkov codec and bt end are being shown on the screen after the crash |
| 21:30:39 | AxelK | 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 | AxelK | 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 | AxelK | 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 | AxelK | I tried opus files encoded with "opusenc" (from opus-tools package) and with ffmpeg and the "-acodec libopus" option, same result |
| 21:35:17 | AxelK | 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 | AxelK | bye |
| 21:35:23 | | Quit AxelK (Quit: Verlassend / Leaving) |
| 21:36:19 | | Part Yst ("<https://y.st/>") |
| 21:48:02 | | Join AxelK [0] (~AxelK@p5790E9D9.dip0.t-ipconnect.de) |
| 21:48:23 | AxelK | Sorry, forgot some important information. |
| 21:50:13 | AxelK | 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 | AxelK | 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 |
| 22:00:11 | | Quit WakiMiko (Quit: WeeChat 1.8-dev) |
| 22:01:26 | | Quit pamaury (Ping timeout: 240 seconds) |
| 22:01:59 | qorx | 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 | qorx | 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 | qorx | If I leave it a 0, it's bad and can't hear decently |
| 22:04:20 | qorx | 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 | saratoga | qorx: the ground pin on your headphone jack isn't making contact, so you're hearing the L-R signal |
| 22:17:55 | saratoga | 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 | qorx | 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 | AxelK | 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 |
| 23:00:39 | *** | Saving seen data "./dancer.seen" |
| 23:00:41 | AxelK | 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 | AxelK | 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 | AxelK | 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 | AxelK | 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 | AxelK | meaning, start playing it and quickly after that (i.e. as quickly as possible) try to fast forward |
| 23:06:14 | AxelK | 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 | AxelK | 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 | AxelK | 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 | AxelK | 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 | AxelK | ffmpeg -i the.mp3 -c:a libopus -b:a 32k testfile.opus |
| 23:14:16 | AxelK | and try that file |
| 23:15:02 | AxelK | or if you want to use a file directly encoded with opusenc (which will also use libopus) |
| 23:15:13 | AxelK | get some longer wav file and encode with |
| 23:15:41 | AxelK | opusenc −−bitrate 32k some.wav test.opus |
| 23:18:13 | AxelK | 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 | AxelK | 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 | AxelK | 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 | AxelK | 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) |
icon identifies that the person is a core developer (has commit access).