--- Log for 08.12.124 Server: mercury.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 9 days and 4 hours ago 00.00.20 # Build Server message: 3New build round started. Revision 9eb9e4ab22, 345 builds, 9 clients. 00.00.20 # 3[Bugfix/Red] fix red in checkwps , fix mp3_encoder plugin div by 0, warnings by William Wilgus 00.16.00 # Build Server message: 3Build round completed after 949 seconds. 00.16.02 # Build Server message: 3Revision 9eb9e4ab22 result: 0 errors 66 warnings 00.20.12 # <_bilgus> dang it 00.28.34 # Build Server message: 3New build round started. Revision ebd1021fe4, 345 builds, 9 clients. 00.28.34 # 3[Bugfix] Pt doesn't return length of the next track by William Wilgus 00.43.10 # Build Server message: 3Build round completed after 877 seconds. 00.43.12 # Build Server message: 3Revision ebd1021fe4 result: All green 01.53.38 *** No seen item changed, no save performed. 02.01.14 Quit chris_s (Quit: Client closed) 02.24.16 Join JanC_ [0] (~janc@user/janc) 02.24.16 Quit JanC (Killed (tantalum.libera.chat (Nickname regained by services))) 02.24.16 Nick JanC_ is now known as JanC (~janc@user/janc) 02.57.17 Quit massiveH (Quit: Leaving) 03.32.32 # _bilgus: if the tag supports both relative and absolute paths, it should be possible to access both inside and outside .rockbox, and by default the relative path resolves from /.rockbox/ 03.33.58 # it's more of a question where should the playername file live 03.34.25 # my 2 cents is that there should be no default file created whatsoever 03.35.06 # and the tag will just skip it, but if anyone needs it, they can create it manually 03.36.24 # i'd refer the cabbie theme to playername.txt so it resolves from /.rockbox/ automatically 03.36.31 # <_bilgus> yep 03.36.37 # <_bilgus> thats what it does 03.36.49 # <_bilgus> no access outside .rockbox 03.37.05 # (i read only the forum post, not the patch yet) 03.37.12 # <_bilgus> default gets created and if you want a different one you go change it 03.37.35 # <_bilgus> (in the .rockbox folder) 03.38.48 # well having a default that simply says it's rockbox, does not bring any new information to the user 03.39.25 # <_bilgus> if you hate Rockbox! flashing every 5 mins you can make it empty to disable 03.39.27 # and if they don't read the manual, as they usually do, and try to delete the file, it will pop up again, and annoy them 03.39.41 # oh, it flashes? 03.40.12 # <_bilgus> no flash and show synonymous .. 03.40.40 # <_bilgus> its a line alternator everything flashes 03.41.40 # I'll check the patch later, to get better understanding 03.43.50 # <_bilgus> basically in cabbie it is added as an alternator to Next: and it displays for 1 second every 5 minutes 03.44.39 # <_bilgus> the %ft part it just reads a line from a file 03.49.20 # <_bilgus> also I wonder if there is some way to take the scrolling line timeouts and adjust them dynamically so really long lines actually get scrolled all the way 03.49.56 # <_bilgus> perhaps some math on scroll speed vs strlen ?? 03.53.40 *** Saving seen data "./dancer.seen" 03.54.00 # Build Server message: 3New build round started. Revision 33cbefb310, 345 builds, 9 clients. 03.54.00 # 3skin_parser Reduce ram usage for conditionals on %ft() file text tags by William Wilgus 03.56.15 Join lebellium [0] (~lebellium@2a01cb0405d07f00d33a0da62bfc2206.ipv6.abo.wanadoo.fr) 04.04.18 Quit jacobk (Ping timeout: 248 seconds) 04.05.04 Join jacobk [0] (~quassel@47-186-65-73.dlls.tx.frontiernet.net) 04.08.42 # Build Server message: 3Build round completed after 883 seconds. 04.08.44 # Build Server message: 3Revision 33cbefb310 result: All green 05.53.43 *** Saving seen data "./dancer.seen" 06.26.15 Quit Skyrider (Quit: ZNC - 1.6.0 - http://znc.in) 06.29.00 Join Skyrider [0] (~Skyrider@static.219.32.201.138.clients.your-server.de) 06.56.28 # user890104: is Rockbox possible to run on Linux aarch64? 06.56.49 # out of curiousity 06.59.22 # uhm, you mean the SDL build? haven't tried yet 07.53.47 *** Saving seen data "./dancer.seen" 08.23.02 # UI Sims (and the "SDL application") build and run fine on aarch64. 08.23.26 # (and even on Arm-based Macs) 08.25.41 Quit Trzyzet (Ping timeout: 248 seconds) 08.29.07 # speachy: is there a ready build for aarch64? want to try it on Ubuntu Touch. 08.33.36 # we do't provide binaries for anything other than standalone (ie fixed) DAPs. 08.34.59 # that said it's not a bad idea to at least have someting like that in the build farm, but then someone has to provide a suitable aarrch64 buulder. 08.38.13 # I'm still working on adding rbutil (and friends) to the build farm but there's still a ton of warnings that need to be dealt with. 08.59.01 Join JanC_ [0] (~janc@user/janc) 08.59.01 Nick JanC is now known as Guest5586 (~janc@user/janc) 08.59.01 Nick JanC_ is now known as JanC (~janc@user/janc) 08.59.22 Quit Guest5586 (Ping timeout: 252 seconds) 09.11.46 Join Trzyzet [0] (~Trzyzet@88.97.248.229) 09.53.48 *** Saving seen data "./dancer.seen" 11.53.50 *** No seen item changed, no save performed. 12.22.03 # Build Server message: 3New build round started. Revision 05a77178ff, 345 builds, 9 clients. 12.22.03 # 3plugins: fix plugin handle reset after plugin load failed by Christian Soffke 12.30.31 Join chris_s [0] (~chris_s@2a09:bac3:2f46:246e::3a1:2b) 12.35.13 # Build Server message: 3Build round completed after 792 seconds. 12.35.15 # Build Server message: 3Revision 05a77178ff result: All green 12.37.20 # Build Server message: 3New build round started. Revision bc1d7d77c5, 345 builds, 9 clients. 12.37.21 # 3FS#13530: Updated Italian translation (Alessio Lenzi) by Solomon Peachy 12.40.59 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) 12.49.30 # Build Server message: 3Build round completed after 730 seconds. 12.49.32 # Build Server message: 3Revision bc1d7d77c5 result: All green 12.58.49 Quit jacobk (Quit: No Ping reply in 180 seconds.) 13.00.31 Join jacobk [0] (~quassel@47-186-65-73.dlls.tx.frontiernet.net) 13.37.58 Quit othello7 (Quit: othello7) 13.50.16 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) 13.53.52 *** Saving seen data "./dancer.seen" 15.12.30 # Build Server message: 3New build round started. Revision ca79fd039c, 345 builds, 9 clients. 15.12.30 # 3skin_parser add empty parser callback remove guard conditionals by William Wilgus 15.15.25 Quit othello7 (Quit: othello7) 15.20.33 Quit akaWolf (Ping timeout: 244 seconds) 15.22.22 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) 15.26.46 # Build Server message: 3Build round completed after 856 seconds. 15.26.48 # Build Server message: 3Revision ca79fd039c result: All green 15.37.10 # Build Server message: 3New build round started. Revision 7b40c1f786, 345 builds, 9 clients. 15.37.10 # 3FS#13531: Minor correction to Turkish Translation (Mustafa YILDIZ) by Solomon Peachy 15.40.51 # <_bilgus> paulcarroty, so I've been pluggin my device and watching the battery debug menu when I start with a full battery I see indeed its 'discharging' knows the charger is connected and the battery level stays pretty consistent as its sitting here do you see similar on your device? 15.41.52 # <_bilgus> next I'm going to try with lower battery say 50% discharged and then leave it connected and watch the debug menu for when it goes from charging to discharging 15.42.52 # <_bilgus> if you could do the same in the next few days we'll compare notes unless I see something before then 15.51.04 # Build Server message: 3Build round completed after 835 seconds. 15.51.05 # Build Server message: 3Revision 7b40c1f786 result: All green 15.53.56 *** Saving seen data "./dancer.seen" 16.02.27 # <_bilgus> So we tried clock stretching with regards to the button system and the difference was within measurement error I wonder what if we doubled the tick_timer interval and increase current_tick by 2 ticks instead 16.04.44 # <_bilgus> so far its working fine I wonder what the upper limit would be before it became apparent 16.10.26 # <_bilgus> I figured crossfade might get screwy but so far no 16.39.24 # <_bilgus> oh yep there it is static on fade in/out that took all of 10 minutes lol 16.41.46 Quit chris_s (Quit: Client closed) 16.53.00 # <_bilgus> OH it wasn't this patch 17.00.32 # <_bilgus> hmm very strange static all over when I play the track I boot into a different version and play the track its fine copy taht fw over to the one thats acting up and boot and the track still has white noise 17.05.39 Join chris_s [0] (~chris_s@140.248.36.54) 17.07.38 # I'm seeing a reproducable crash at the moment when loading up (some?) MP3s on device (iPod video), trying to figure out the responsible commit 17.18.25 # <_bilgus> sounds like it could be related I'm trying to figure out just what is causing it, config settings aren't it 17.21.48 # <_bilgus> this is really weird I took the same file and copied it over the other and it works fine, I think it leaves the nvram file already saved it 17.23.59 # <_bilgus> hmm so copying over the nvram file is the ticket 17.25.02 # bcc8c60 still seems good, checking the more recent ones 17.29.18 # if I had to guess, b14056e 17.30.31 # looks like it, yes 17.33.46 # time for a revert, eh? 17.34.32 # well, it's definitely it 17.34.43 # <_bilgus> how is that different 17.35.33 # Build Server message: 3New build round started. Revision f48d1aeb27, 345 builds, 9 clients. 17.35.34 # 3S5L8702, S5L8720: Add VIC init, prepare for iPod Nano 3G and iPod Nano 4G by Vencislav Atanasov 17.35.36 # <_bilgus> &D[-p] is indeed D-p correct? 17.38.25 # the patch is wrong anyway; there are mulitple places that exact construct is used (different CPU arches) 17.39.36 # ie L716 too (and possibly in some asm code?) 17.41.11 # I think (void*)D-p is subtracting p from a void* pointer, whereas (void*)&D[0][-p] is casting D[-p] to a void* 17.41.30 Join MarcAndersen [0] (~no_znepna@217.74.221.70) 17.41.39 # D[] being madfixed_t. 17.41.52 # Is there sound output on the nano 3g or 4g yet? 17.44.34 # so g#6166 17.44.36 # 3Gerrit review #6166 at https://gerrit.rockbox.org/r/c/rockbox/+/6166 : 3Revert "libmad synth.c silence warnings" by Solomon Peachy 17.45.30 # MarcAndersen: nope. IIUC the nano3g should be to that point by the end of the year, but nano4g will need further work. 17.45.56 # neither has a realistic ETA on the NAND FTL yet. 17.46.17 # I Have one of those things around somewhere, but apple decided not to put voiceover on them... 17.46.18 # (ie no usable onboard storage) 17.46.47 Quit chris_s (Quit: Client closed) 17.48.16 # I need to find out if it's a 3 or 4g. Are they the same size, I mean the physical device 17.48.56 # I don't know, but my guess would be no; apple kept changing up the physical form factor on the nanos 17.49.33 Join chris_s [0] (~chris_s@2a09:bac3:2fa4:1282::1d8:18c) 17.49.41 # yeah, 3rd gen is squareish, 4th gen is rectangular. 17.49.45 # I need to get it plugged in. I should be able to look up it's serial number 17.49.57 # <_bilgus> Sure enough that solved it 17.50.20 # <_bilgus> I'm going to have to try it without the cast and see if it works 17.50.39 # It's not that regtangular, maybe it's a 3g, I hope so. 17.51.52 # 5th gen is also a rectangle, 6th gen is square and ditches the clickwheel in favor of a multitouch UI. 17.52.47 # I'm almost sure it's a 3g. Right now it plugs in, out, in, out because of the battery is run out 17.53.48 Quit lebellium (Quit: Leaving) 17.53.57 *** Saving seen data "./dancer.seen" 17.54.18 # I'm subscribed to the git cvs mailing list so I get all the commits in my inbox. I should be able to figure out when it's ready that way. 17.54.20 # Build Server message: 3Build round completed after 1127 seconds. 17.54.21 # Build Server message: 3Revision f48d1aeb27 result: All green 17.56.51 # Yes! It was a 3g. 17.57.02 # <_bilgus> black magic hardware stuff apparently 17.58.02 # But once there is something for it I probably need some help installing it. 17.58.13 # <_bilgus> Oh nvm I see it 17.59.22 # <_bilgus> that is equivalent but since its negative the pointer math does and implicit jump of the prior element size 18.00.05 # <_bilgus> D-p would be D[-p] but it has multiple dimensions 18.00.39 # <_bilgus> lets see if I'm right I mean I have a pretty good litmus test 18.07.54 # <_bilgus> hell IDK thats not it either 18.12.34 # I think it's pretty much what speachy wrote, i.e. you're stepping back by p bytes instead of (p*4) (for int32_t) bytes, at least that's what Godbolt seems to indicate 18.17.43 # <_bilgus> yeah thats what I figured but trying it doesn't work so just some weird pointer stuff trying to do it in godbolt just has errors though so IDk 18.18.37 # <_bilgus> :14:30: error: invalid conversion from 'void*' to 'const mad_fixed_t (*)[32]' 18.21.28 # <_bilgus> its making a index table from the looks of it 18.34.18 # Would this work? 18.34.22 # (void *)(D[0] - p) 18.39.02 # <_bilgus> trying it 18.40.09 # <_bilgus> that works 18.40.53 # <_bilgus> godbolt still doesn't like it though 18.42.14 # it's entirely valid C that builds cleanly for all of our targets; let's not break from what upstream wrote. 18.43.13 # godbolt breaking on this is a bug in godbolt. 18.44.43 # <_bilgus> fair enough 18.45.56 # <_bilgus> runtime error: load of address 0x719b6c78159c with insufficient space for an object of type 'const mad_fixed_t' gcc doesn't like it either tbf 18.46.09 # <_bilgus> cursed. 18.47.15 # <_bilgus> fixed math and building for speed.. 18.54.33 # <_bilgus> hmm looking upstream it doesn't have that -p shit 18.55.29 # <_bilgus> only the D0 one 18.55.42 # <_bilgus> DPtr in their case 18.58.52 # <_bilgus> https://github.com/Rockbox/rockbox/commit/f004315105cf2c829800bf9e20e55e6efaf6a050 18.59.28 # <_bilgus> Patch #5219 by Antonius Hellmann. Several optimisations to libmad. Both Coldfire and ARM targets should benefit much from this. 19.00.17 # <_bilgus> does it though? 19.00.25 # <_bilgus> or is it bad code? 19.01.06 # <_bilgus> i'm going to try the actual upstream code 19.01.34 # <_bilgus> so since its no longer clean is it ok to poke it with a stick? 19.02.38 # <_bilgus> I want to see it it fixes this audio break up in the sim first 19.03.02 # <_bilgus> that alsa trick appeared to knock it back a bit but its v noticable still 19.05.29 # <_bilgus> I think I'd like to have a look at what the compiler spits out with upstream versus ours 19.06.23 # imo it make sense to still revert the commit to fix the crash in the short term? (and possibly follow up with larger changes) 19.09.11 # just for the benefit of anyone downloading the current dev build... I may be overestimating download traffic for bleeding-edge builds though 19.11.22 # yes ^^ this 19.11.37 # well, we tell folks to "don't use stable" these days so... yeah 19.11.58 # what spanwed this rabbit hole anyway? 19.13.11 # <_bilgus> Oh I just saw the warnings and was wondering if changing one would fix it 19.13.48 # <_bilgus> I thought speachy already pushed it 19.13.56 # no, just proposed. I'll push it. 19.14.03 # Build Server message: 3New build round started. Revision e3323e3ba7, 345 builds, 9 clients. 19.14.03 # 3Revert "libmad synth.c silence warnings" by Solomon Peachy 19.14.53 # the choppy audio in the sim is due to our use of sigalstack threading, which means we can't use a dedicated audio thread 19.15.13 # <_bilgus> why is it just now showing up though? 19.15.13 # if you use SDL_AUDIODRIVER=alsa it goes away for me actually 19.15.38 # <_bilgus> that helped but there is still a very noticable hiss and pop in the top end 19.15.50 # it depends on how your local SDL was compiled 19.16.17 # I cna't comment on hiss/pops 19.16.58 # <_bilgus> almost like clipping but more garbled data missing corrupted is what it sounds like 19.18.16 # on all sims? does it also do it with the "sdl application" ? 19.18.50 # another thing to consider is that we can't really control the toolchain with sims etc 19.19.02 # so there's a lot more potential for fun there 19.19.41 # might be worth mucking with CFLAGS etc to force a 32-bit sim build vs 64-bit 19.20.10 # <_bilgus> yeah may force some optimizations or move some stuff around 19.20.44 # <_bilgus> I'll check the app in the next few I was getting ready to switch to that when that synth thing came biting 19.22.09 # (eg that sound problem dconrad had with the erosqnative sim build -- a #define wasn't disabled for sims causing us to try and push 24-bit audio into 16-bit SDL audio paths. 19.24.05 # ...It's pretty normal for bunches of new sim warnings to show up when someone (typically me) updates a bulilder to use the newest toolchains 19.25.54 # Would you be able to update https://www.rockbox.org/wiki/UiSimulator.html with info on building with sdl2 for windows from linux? 19.28.12 # Build Server message: 3Build round completed after 849 seconds. 19.28.14 # Build Server message: 3Revision e3323e3ba7 result: All green 19.30.24 # _bilgus: when you say "just now showing up" what kind of timeline are you referring to? wg we moved from SDL1->SDL2 in October 19.30.29 # I also see you are refering to i586-mingw32msvc which I didn't even know about. It must be very old. 19.30.45 # eww, yeah. 19.31.47 # I am thinking about reinstalling a linux machine with only the rockbox stuff on it and I want to do it correctly so I don't install a lot of conflicting packages. 19.32.45 # Now the link to my page is on your wiki I need to keep up :) 19.32.53 Quit sch (Remote host closed the connection) 19.33.31 Quit bpye (Quit: Ping timeout (120 seconds)) 19.34.07 Join bpye [0] (~bpye@user/bpye) 19.49.21 Join massiveH [0] (~massiveH@2600:4040:a982:5400:d0e8:cd89:17f3:feca) 19.50.40 Join bilgusph [0] (~bilgusph@2600:1702:3810:17f0:2dbc:ccd3:75fe:721) 19.51.45 # Speachy sdl2 was fine its only been since i moved to ububtu 24 and the newest GCC 19.52.01 # Want to say old was gcc8 19.53.55 Quit bilgusph (Client Quit) 19.54.00 *** Saving seen data "./dancer.seen" 21.54.03 *** No seen item changed, no save performed. 22.02.31 Quit othello7 (Ping timeout: 244 seconds) 22.43.44 # <_bilgus> So upstream v1.25 crashes with asan LOL 22.43.57 # <_bilgus> libmad 22.48.04 # hah, that's funny. 22.48.13 # codecs are always kinda special 22.57.38 # <_bilgus> yeah I normally try to stay far away 23.06.25 Quit massiveH (Quit: Leaving) 23.54.06 *** Saving seen data "./dancer.seen"