--- Log for 06.05.124 Server: tungsten.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 15 days and 15 hours ago 00.26.08 Join CH23[m] [0] (~CH23@revspace/participant/ch23) 00.36.15 Quit othello7 (Ping timeout: 268 seconds) 00.40.49 *** Saving seen data "./dancer.seen" 00.59.11 Quit CH23[m] (Remote host closed the connection) 00.59.21 Join CH23[m] [0] (~CH23@revspace/participant/ch23) 01.15.27 Join decky [0] (~decky_@69.9.138.178) 01.18.36 Quit decky_e (Ping timeout: 255 seconds) 01.20.24 Quit decky (Read error: Connection reset by peer) 01.21.08 Join decky [0] (~decky_@69.9.138.178) 01.48.24 Quit decky (Read error: Connection reset by peer) 01.48.50 Join decky [0] (~decky_@69.9.138.178) 02.02.05 Quit jacobk (Ping timeout: 240 seconds) 02.27.25 Join jacobk [0] (~quassel@utdpat241033.utdallas.edu) 02.40.52 *** Saving seen data "./dancer.seen" 02.42.28 Quit PheralSparky (Quit: Leaving) 03.29.30 # _bilgus_, I think the bootloader from 2023-12-26 is the one you sent me back then and which I'm already using 03.29.45 # and you can boot to a 128GB card with that? :( 04.40.55 *** Saving seen data "./dancer.seen" 06.02.23 Quit jacobk (Ping timeout: 260 seconds) 06.19.20 # https://uc.xmpp.zombofant.net/beaf2fa2-3396-48b1-b837-4988ebffeebb/XoORxvIESK-gEh892WlmcQ.jpg the middle card is the non-working one and the right one is the one I currently use in my player. left is an unrelated card for comparison. 06.19.31 # either sandisk changed their colours or something fishy is going on here. 06.32.20 Join jacobk [0] (~quassel@47-186-70-49.dlls.tx.frontiernet.net) 06.40.01 Join chris_s [0] (~chris_s@ip-037-201-213-053.um10.pools.vodafone-ip.de) 06.40.21 # speachy: re the sim migration to sdl2 you've mentioned - it's been working fine on MacOS. I remember running into some issue trying to compile the same code on Linux, though. 06.40.29 # Didn't follow up on it, since there was no pressing need. I'll have to take a look at it again. 06.40.59 *** Saving seen data "./dancer.seen" 07.11.23 Quit chris_s (Ping timeout: 264 seconds) 08.04.00 # thank you 08.04.45 # I can't imagine it'll be much of a challenge to resolve the issues on Linux. 08.05.45 # oh, one thing I noticed when looking at the patches (which you may have fixed in later patches) was the mousewheel support removal, SDL2 uses a differnt mechanism for that unfortunately. 08.41.02 *** Saving seen data "./dancer.seen" 09.09.49 Quit CH23[m] (Ping timeout: 246 seconds) 09.11.09 Join CH23[m] [0] (~CH23@revspace/participant/ch23) 09.37.18 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) 09.44.27 Quit wLLm (Quit: ZNC - https://znc.in) 09.54.29 # <_bilgus_> so if we bump NVRAM_CONFIG_VERSION I think that will allow us to wipe out old nvram files on copy updates 09.55.38 # <_bilgus_> jssfr, yes been using it with one since before those bootloaders actually 09.55.47 # is the problem that we haven't been doing this when we should have? 09.55.59 # or just that we have some corrupted nvdata files. 09.56.16 # <_bilgus_> I don't actually know when we last changed it tbh 09.56.55 # <_bilgus_> thats possible too but it does have crc checks 09.57.38 # wow. 09.57.47 # 31b71228672 (Michael Sevakis 2013-07-14 07:59:39 -0400 148) #define NVRAM_CONFIG_VERSION 8 09.57.48 # <_bilgus_> you'd think if i was corruption itd just discrd it 09.58.40 # <_bilgus_> heh 11 years ago 10.00.23 # I don't think there's been an NVRAM setting change (at least not in settings_list) since then 10.01.04 # though it's conceivable somethign changed in the interim 10.01.22 Join f_ [0] (~AUGESOUND@fases/developer/funderscore) 10.02.48 Quit othello7 (Quit: othello7) 10.03.59 # <_bilgus_> yeah the nvram setting he added had the version bump 10.04.25 # there's a more recent update to that but that was just reformatting 10.05.30 # <_bilgus_> I also don't see anything for the tuner except last_frequency 10.06.43 # should there be? 10.08.56 # hmm, resume_elapsed might need to be a 64-bit value now 10.09.17 # given that we had to go to 64-bit seek offsets in a few of the codecs 10.09.59 # or if it's seconds, we're ok, nevermind 10.13.32 # <_bilgus_> so I see a function snap_freq_to_grid() but it doesn't look like its applied on the incoming resume frequency 10.14.11 # <_bilgus_> I wonder if the tuner gets weird if you send values outside of the expected range 10.14.26 # probably 10.14.50 # <_bilgus_> i'll try messing around with it and save some weird values and see if it freaks out 10.17.37 Join wLLm [0] (~wLLm@45.83.5.161) 10.18.39 # <_bilgus_> we have a winner 10.19.00 # <_bilgus_> immediate hang 10.19.35 # <_bilgus_> ok so that doesn't say how the value got out of range 10.19.46 # <_bilgus_> I wonder if switching regions would do it 10.20.06 # that could easily do it 10.20.56 # <_bilgus_> I assume snap_to_grid would pull new values when modes change so in theory it should just work 10.25.33 # worth double checking 10.32.03 # Build Server message: 3New build round started. Revision 30482bd908, 304 builds, 9 clients. 10.32.03 # 3[BugFix] Radio make sure resume frequency is in range by William Wilgus 10.35.20 # <_bilgus_> i'll double check but /* Keep freq on the grid for the current region */ kinda led me to it :p 10.37.09 # <_bilgus_> yeah it pulls in a table of regions based on the current global 10.38.19 # <_bilgus_> so likely they got out of sync and the tuner was in one mode and the nvram file saved a freq outside that region 10.38.52 # <_bilgus_> I updated the FS close report 10.39.41 # <_bilgus_> talk about some lottery chances 10.41.00 # <_bilgus_> should have asked the user to still send me the nvram file 10.41.04 *** Saving seen data "./dancer.seen" 10.41.47 # <_bilgus_> oh nm I did 10.42.54 # Build Server message: 3Build round completed after 651 seconds. 10.42.55 # Build Server message: 3Revision 30482bd908 result: All green 10.43.20 # w00t, completely green board again 10.43.35 # I'll probably change that when I get the xrick commit in. 10.44.26 # but $dayjob takes priority 10.57.41 Quit jacobk (Ping timeout: 240 seconds) 10.59.10 Join jacobk [0] (~quassel@47-186-70-49.dlls.tx.frontiernet.net) 11.07.41 Quit jacobk (Ping timeout: 240 seconds) 11.08.48 Join jacobk [0] (~quassel@64.189.201.150) 11.09.59 Quit CH23[m] (Read error: Connection reset by peer) 11.11.02 Join CH23[m] [0] (~CH23@revspace/participant/ch23) 11.18.31 Quit f_ (Quit: To contact me, send a memo using MemoServ, PM f_[xmpp], or send an email. See https://vitali64.duckdns.org/.) 11.19.31 Join f_ [0] (~AUGESOUND@fases/developer/funderscore) 11.24.59 Quit jacobk (Ping timeout: 268 seconds) 11.30.25 Quit speachy (Quit: WeeChat 4.2.2) 11.40.37 Join speachy [0] (~speachy@hurricane.shaftnet.org) 11.40.37 Quit speachy (Changing host) 11.40.37 Join speachy [0] (~speachy@rockbox/developer/speachy) 11.40.37 Mode "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) 11.59.53 Join CH23_ [0] (~CH23@revspace/participant/ch23) 12.05.39 Quit CH23[m] (Read error: Connection reset by peer) 12.06.21 Join CH23[m] [0] (~CH23@revspace/participant/ch23) 12.06.40 Join davisr [0] (~davisr@fsf/emeritus/davisr) 12.08.57 Quit CH23_ (Ping timeout: 252 seconds) 12.09.23 Quit CH23 (Ping timeout: 268 seconds) 12.15.09 Quit CH23[m] (Ping timeout: 255 seconds) 12.15.25 Join CH23[m] [0] (~CH23@revspace/participant/ch23) 12.35.16 Quit user890104 () 12.37.28 Join user890104 [0] (~Venci@freemyipod/user890104) 12.41.08 *** Saving seen data "./dancer.seen" 12.42.33 Quit CH23[m] (Read error: Connection reset by peer) 12.42.53 Join CH23[m] [0] (~CH23@revspace/participant/ch23) 13.38.29 Quit f_ (Quit: To contact me, send a memo using MemoServ, PM f_[xmpp], or send an email. See https://vitali64.duckdns.org/.) 14.04.35 Join CH23 [0] (~CH23@revspace/participant/ch23) 14.10.57 Join PheralSparky [0] (~Shawn@user/shawn/x-4432647) 14.19.29 Join lebellium [0] (~lebellium@2a01cb0405d07f00c4d184929e98f314.ipv6.abo.wanadoo.fr) 14.41.12 *** Saving seen data "./dancer.seen" 15.44.06 Quit CH23 (Ping timeout: 256 seconds) 16.41.16 *** Saving seen data "./dancer.seen" 16.49.48 Join CH23 [0] (~CH23@revspace/participant/ch23) 16.52.20 Quit tertu2 (Quit: so long...) 16.52.52 Join tertu [0] (~tertu@user/tertu) 17.13.17 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) 17.31.21 # Build Server message: 3New build round started. Revision ee840709d3, 304 builds, 9 clients. 17.31.22 # 3[Feature] Open plugins now recognizes known filetypes and can run them by William Wilgus 17.42.45 # you didn't bump the plugin api revision.. 17.44.05 # Build Server message: 3Build round completed after 765 seconds. 17.44.08 # Build Server message: 3Revision ee840709d3 result: 0 errors 278 warnings 17.44.15 # aaand there went the green. :D 17.45.01 # if we were metrics-driven you'd be in so much trouble now 17.58.21 # <_bilgus_> bah 18.02.07 # Build Server message: 3New build round started. Revision 3348d84206, 304 builds, 9 clients. 18.02.07 # 3open_plugins Fix Yellow by William Wilgus 18.03.46 # <_bilgus_> shit they probably fire me at this point I bet 18.04.08 # sorry, no bonus for you this quarter 18.06.21 # <_bilgus_> that was supposed to be 100x my normal pay! 18.06.49 # so... $0? 18.11.18 # Build Server message: 3Build round completed after 551 seconds. 18.11.19 # Build Server message: 3Revision 3348d84206 result: All green 18.11.39 # <_bilgus_> I did save 32 bytes with that 18.24.10 Quit lebellium (Quit: Leaving) 18.41.19 *** Saving seen data "./dancer.seen" 19.41.31 Join massiveH [0] (~massiveH@2600:4040:a982:c800:e984:275:8cda:2345) 20.41.22 *** No seen item changed, no save performed. 21.02.38 Quit davisr (Remote host closed the connection) 22.41.24 *** Saving seen data "./dancer.seen" 22.54.41 Quit massiveH (Quit: Leaving) 22.58.26 Quit pixelma (Ping timeout: 268 seconds) 22.59.03 Quit amiconn (Ping timeout: 268 seconds) 23.00.58 Join amiconn [0] (jens@p200300ea87348b00305e95fffec66ff3.dip0.t-ipconnect.de) 23.01.37 Join pixelma [0] (marianne@p200300ea87348b00305e95fffec66ff3.dip0.t-ipconnect.de) 23.29.14 Join braewoods_ [0] (~braewoods@user/braewoods) 23.30.02 Quit braewoods (Read error: Connection reset by peer)