Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2021-02-16

00:23:25 Quit ac_laptop (Ping timeout: 240 seconds)
01:00
01:27:14 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
01:31:33 Quit ZincAlloy (Ping timeout: 246 seconds)
01:37:57 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:8484:4444:49a5:f7db)
01:41:26 Quit PicklesTheFrog1 (Ping timeout: 264 seconds)
01:42:47 Quit ZincAlloy (Ping timeout: 272 seconds)
01:56:00***Saving seen data "./dancer.seen"
01:56:57 Quit pixelma (Quit: .)
01:56:57 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
01:59:38 Join amiconn [0] (~jens@rockbox/developer/amiconn)
01:59:38 Join pixelma [0] (~marianne@rockbox/staff/pixelma)
02:00
02:01:39 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
02:47:10 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:9c4a:6b88:4fe3:89c4)
02:47:25 Quit ZincAlloy (Client Quit)
02:47:34 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:9c4a:6b88:4fe3:89c4)
02:49:10 Quit ZincAlloy (Client Quit)
02:58:53 Join Rower [0] (~Rower@84.17.55.74)
03:00
03:11:03 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
03:20:47 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
03:32:25 Quit pamaury (Ping timeout: 240 seconds)
03:56:04***Saving seen data "./dancer.seen"
05:00
05:34:47 Quit koniu (Remote host closed the connection)
05:51:27 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
05:56:06***Saving seen data "./dancer.seen"
06:00
06:47:40speachythere are also multiple 'mdat' sections in the problematic files, though we're barfind on the OOM problem before we could get tanked on that.
07:00
07:18:55 Quit k1w1 (Quit: k1w1)
07:21:35 Join k1w1 [0] (~k1w1@unaffiliated/k1w1)
07:24:55 Quit k1w1 (Read error: Connection reset by peer)
07:25:20 Join k1w1 [0] (~k1w1@unaffiliated/k1w1)
07:53:14 Quit Rower (Remote host closed the connection)
07:56:09***Saving seen data "./dancer.seen"
08:00
08:19:14 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de)
08:20:12 Part chris_s
09:00
09:04:00 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
09:06:32 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09:22:42speachyc
09:24:10speachythe combination of cats and focus-follows-pointer make for unpredictible inputs
09:42:32 Quit J_Darnley (Ping timeout: 265 seconds)
09:44:02 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be)
09:56:10***Saving seen data "./dancer.seen"
10:00
10:13:08cockroach:)
10:46:16 Quit massiveH (Ping timeout: 240 seconds)
11:00
11:52:28 Join remihacker5 [0] (~remihacke@pax.irondistrict.org)
11:55:52 Join remihacker5_ [0] (~remihacke@vpn.irondistrict.org)
11:56:14***Saving seen data "./dancer.seen"
11:56:35 Quit remihacker5_ (Client Quit)
11:57:38 Quit remihacker5 (Quit: Leaving)
11:58:01 Join remihacker5 [0] (~remihacke@pax.irondistrict.org)
12:00
12:04:27 Quit remihacker5 (Quit: Leaving)
12:04:29 Join remihacker5_ [0] (~remihacke@pax.irondistrict.org)
12:04:47 Quit remihacker5_ (Client Quit)
12:05:07 Join remihacker5 [0] (~remihacke@vpn.irondistrict.org)
12:05:36 Quit remihacker5 (Client Quit)
12:39:13 Join MrZeus__ [0] (~MrZeus@2a02:c7f:a0aa:4400:d4e9:415c:7d69:2bd5)
12:40:12 Join lebellium_ [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
12:43:26 Quit lebellium (Ping timeout: 256 seconds)
13:00
13:00:08 Quit MrZeus__ (Read error: No route to host)
13:01:40 Join MrZeus__ [0] (~MrZeus@57504f25.skybroadband.com)
13:04:57 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
13:33:37 Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-43568247.dyn.optonline.net)
13:56:15***Saving seen data "./dancer.seen"
14:00
14:13:43 Join PicklesTheFrog [0] (~PicklesTh@2601:640:8780:a820:cc83:eb9b:74c0:a0ba)
14:19:36 Join MrZeus_ [0] (~MrZeus@194.37.96.119)
14:23:32 Quit MrZeus__ (Ping timeout: 272 seconds)
15:00
15:06:44 Join PicklesTheFrog1 [0] (~PicklesTh@2601:640:8780:a820:cc83:eb9b:74c0:a0ba)
15:12:49 Quit PicklesTheFrog (Quit: Leaving)
15:12:50 Join PicklesTheFrog12 [0] (~PicklesTh@2601:640:8780:a820:cc83:eb9b:74c0:a0ba)
15:12:53 Quit PicklesTheFrog12 (Remote host closed the connection)
15:13:15 Quit PicklesTheFrog1 (Quit: Leaving)
15:13:41 Join PicklesTheFrog1 [0] (~PicklesTh@2601:640:8780:a820:cc83:eb9b:74c0:a0ba)
15:50:21popcorn9499speachy: Ahh that makes sense. I discovered that if I used mp4chaps with the nero chapter format rockbox on my ipod classic accepts it fine. however if its using the quicktime format it fails to play and skips to whatever is next in the directory.
15:56:20***Saving seen data "./dancer.seen"
16:00
16:08:41speachypopcorn9499: I don't think it actually has anything to do with the chapter format; instead it has to do with the granularity of the seek points. on the pathological file I ran into a couple of years ago, there are about 110K for a 16-hour file
16:11:03speachywhich is like one every 0.5 seconds
16:15:25popcorn9499I honestly am not positive but wouldnt the amount of seekpoints be the same regardless of which codec audio is encoded with? Or is this set at encode/transcode time?
16:16:14popcorn9499Anyways the only reason i tried chapter formats was it seemed like a easy thing to try. and for me it seemed to fix my issue with rockbox giving up trying to play something back
16:29:13speachyit has to do with the size of each logical chunk of audio data
16:30:07speachyit's not the encoder/codec per se, but how teh data was organized into the mpeg stream container
16:53:41popcorn9499I understand. But why would me switching the flag for what mp4chaps is using to import chapters into a given m4b file change that much that it breaks? Or is it doing far more behind the scenes than just putting in some chapters. I honestly am not sure how the format works exactly byte for byte. But from what im understanding it completely is reformatting the data in the container if the one works and the other doesn't
17:00
17:03:00 Join fs-bluebot [0] (~fs-bluebo@55d49f70.access.ecotel.net)
17:03:03 Quit bluebrother (Disconnected by services)
17:03:08 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
17:05:11 Join berber [0] (~berber@v2202101107577140883.nicesrv.de)
17:05:21 Quit fs-bluebot_ (Ping timeout: 264 seconds)
17:08:17berberhey guys! i have an xduoo x3 and am loving it. i noticed that on one album i had, the audio was glitched, but only on that album. the audio also always glitched the exact same way when i played it over and over again, so it doesn't seem like the processor screwing up or something. i noticed that this album was the only album that was 48khz
17:08:17berberflac, the others were 44.1 khz flac. i converted it to wav and then it worked fine, but still, it would be cool if i got it to work without that, as wav consumes more space and wav doesn't support tagging.
17:08:25berberdoes anyone else have the same issues?
17:27:02berberhm weird, it only happens with a very specific album. i just tried a 96khz album, no glitches so far
17:27:33 Quit ac_laptop (Ping timeout: 264 seconds)
17:36:40popcorn9499out of my own curiosity try converting back to flac @berber
17:37:18berberpopcorn9499: i just tried a different album with 48khz. no glitches
17:37:35berbersomething is weird with that one album. it happens on multiple songs of that album
17:37:44berberpopcorn9499: i will try it
17:39:19berberi tried to redownload it, move it to a different SD card, still the exact same glitches. at the exact same moments
17:39:32berberand when i play it on my pc it works fine, no glitches
17:48:01berberpopcorn9499: what the heck
17:48:04berberno glitches
17:48:25berberthere is no tagging tho, it would be weird to suggest that that made the difference
17:48:51berberi also selected it directly from the file, it's not loaded in the database obviously, since there is no tagging
17:48:59berberidk if that should make any difference, it really shouldn't
17:52:04 Quit ZincAlloy (Quit: Leaving.)
17:52:48berberwhat the hell is going on
17:53:21berberit only happens on my portable player. not on my computer. and it stopped happening once i did what you said. convert it to flac and then back to wav.
17:53:32berber*convert it to wav and then back to flac
17:56:24***Saving seen data "./dancer.seen"
17:58:46speachyit could be something specific to the flac file/decoder. rockbox's flac snapshot is quite old
17:59:05speachyie some specific sequence of bits that isn't handled properly
17:59:36speachyberber: do you have any other rockbox-capable gear? (basically, does that same flac file glitch on other targets?)
18:00
18:00:03speachy(I'd be willing to bet it will glitch on our other targets too)
18:00:11speachy(and in the simulator!)
18:02:44berberspeachy i don't have any other rockbox capable gear
18:02:51berberwhat's the simulator?
18:04:31speachypopcorn9499: I suspect that yes, a lot more is going on behidn the scenes.. it's likely "repacking" the data differently −− and more importantly, regenerating the indices.
18:06:41speachyberber: https://www.rockbox.org/wiki/UiSimulator
18:08:07berberthis makes me paranoid. what i mean is that from now on i will always download stuff as wav and convert it to flac manually, and i would have to index it all manually. oof.
18:08:23berberwell, there is only one album affected
18:08:30berberso maybe i shouldn't be paranoid
18:08:59speachyopen a bug ticket, and if possible, attach one of the files that glitch
18:10:25speachyI have a hard time believing the problem is somehow X3-specific; it's generic C code and the X3 is pretty much the fastest native port we have
18:11:04speachywhen you say "glitch", do you mean the audio skips, drops out, has some sort of audible artifact...?
18:13:53berberaudible artifact
18:14:04berbera sharp high pitched very short noise
18:14:13berberevery now and then
18:14:37berberi'm not able to build the simulator
18:14:51berber /bin/sh: line 1: arm-elf-eabi-gcc: command not found
18:15:02berberi can't seem to find that dependancy for arch linux
18:15:06 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
18:15:30speachywhen you do the ./configure step, you need to select "S" for the sim build
18:16:01speachy(and the X3 build should never try to launch arm-elf-eabi-gcc; it's a mips target)
18:16:43berberah ok thx
18:18:56berberthere is no "rockboxui" in my build directory after following the steps
18:19:57speachymake && make install
18:21:14berberwait sry i screwed up haha i should work it out myself before asking here quickly haha
18:25:41berberyupp
18:25:45berberexact same audio glitch
18:27:00berberi simulated it with the x3 build tho. let me simulate it with an ipod build or something
18:29:57speachythat won't matter; it's running natively on your system
18:31:54berberreally?
18:31:56berberhm
18:32:00speachyour flac code dates pre-2011.
18:32:20speachylate 2005, more precisely.
18:37:49berberi gotta go to sleep now, but this was an interesting night for me. should i open a bug report tomorrow? speachy
18:37:56speachyyes please
18:38:17berberhow should i attach the file? send a cloud link?
18:53:04 Quit cockroach (Quit: leaving)
19:00
19:07:05 Quit Acou_Bass (Ping timeout: 240 seconds)
19:07:58speachyif the file's not too large it can be direcly attached to the bug ticket.
19:08:07speachyit provices a way to upload.
19:56:27***Saving seen data "./dancer.seen"
20:00
20:08:13 Join FroggestSpirit [0] (18c0819f@d192-24-159-129.try.wideopenwest.com)
20:08:39FroggestSpiritWhat would cause a codec to work on the SDL port, but not an M3K for example? I configured both to use 32 GB RAM
20:09:32FroggestSpiritI was working on porting over my Nintendo DS music player, I got it to run in the SDL port, but choosing a song after compiling for M3K, just skips it
20:13:26FroggestSpiritI mean 32MB
20:14:11 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
20:19:20 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
20:28:40speachyMost likely is that the codec is using more memory than is allocated to codecs.
20:29:23speachybut enabling logf/debug and selective DEBUGFs later should help narrow that down considerably
20:29:49speachyanother possibility is floating point or per-arch optimizations in the codec.
20:32:06FroggestSpirityep, it's floating point
20:33:16FroggestSpiritI lazily recasted it to int16 on SDL, so I guess I know it atleast works, I'll just need to take out the floating point (the first version of it I wrote years ago had no floating point in it)
20:33:53FroggestSpiritthanks for the pointer!
20:34:05 Quit FroggestSpirit (Quit: Connection closed)
20:35:55 Quit MrZeus_ (Ping timeout: 272 seconds)
20:45:32 Quit koniu (Ping timeout: 268 seconds)
20:58:27 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
21:00
21:41:08PicklesTheFrog1whats your guys' daily driver with rockbox installed?
21:41:23mendel_munkissansa fuze+
21:47:28popcorn9499speachy: that makes sense. thanks for helping me understand what was likely going on behind the scenes. Any idea if this will be something fixed or highly unlikely?
21:56:28***Saving seen data "./dancer.seen"
22:00
22:00:13 Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
22:00:35 Quit ufdm (Read error: Connection reset by peer)
22:05:44 Quit ac_laptop (Quit: WeeChat 3.0)
22:06:04 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
22:10:44 Quit ac_laptop (Ping timeout: 265 seconds)
23:00
23:04:47 Quit cockroach (Quit: leaving)
23:46:21 Quit koniu (Remote host closed the connection)
23:46:43 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
23:56:30***Saving seen data "./dancer.seen"

Previous day | Next day