--- Log for 23.11.124 Server: zinc.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 23 days and 16 hours ago 00.34.42 *** No seen item changed, no save performed. 00.56.38 Quit massiveH (Read error: Connection reset by peer) 00.59.25 Join massiveH [0] (~massiveH@2600:4040:a982:5400:c876:a78d:705c:ee8f) 01.29.07 Quit speachy (Quit: WeeChat 4.4.3) 01.31.02 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 01.31.02 Quit pixelma (Quit: .) 01.31.59 Join pixelma [0] (marianne@p4fe76649.dip0.t-ipconnect.de) 01.32.00 Join amiconn [0] (jens@p4fe76649.dip0.t-ipconnect.de) 02.10.55 Quit massiveH (Read error: Connection reset by peer) 02.34.44 *** Saving seen data "./dancer.seen" 04.03.33 Quit Bobathan_ (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) 04.04.09 Quit jacobk (Ping timeout: 260 seconds) 04.04.46 Join jacobk [0] (~quassel@47-186-65-73.dlls.tx.frontiernet.net) 04.05.24 Join Bobathan_ [0] (~admin@syn-065-029-248-157.res.spectrum.com) 04.20.34 Join lebellium [0] (~lebellium@2a01cb0405d07f00c0289762e3b7c2bf.ipv6.abo.wanadoo.fr) 04.34.45 *** Saving seen data "./dancer.seen" 04.36.15 Quit berber_l517 (Quit: Ping timeout (120 seconds)) 06.34.46 *** Saving seen data "./dancer.seen" 08.21.33 Quit Natch (Remote host closed the connection) 08.34.50 *** Saving seen data "./dancer.seen" 08.42.53 # in a parallel universe, there could have been ipod nanos with SD card slot - the S5L87xx SoC family has support for SDCI (Secure Digital Card Interface) 09.02.52 Join chris_s [0] (~chris_s@2a09:bac2:2b74:2464::3a0:12) 09.05.41 # Build Server message: 3New build round started. Revision 46a4361bf1, 345 builds, 9 clients. 09.05.42 # 3playlist viewer: move on-disk playlist struct to playlist.c by Christian Soffke 09.21.51 # Build Server message: 3Build round completed after 970 seconds. 09.21.53 # Build Server message: 3Revision 46a4361bf1 result: All green 09.24.30 Join Everything [0] (~Everythin@46.211.85.22) 09.49.09 Quit Everything (Ping timeout: 245 seconds) 09.51.31 Join Everything [0] (~Everythin@46-133-33-209.mobile.vf-ua.net) 10.02.06 Join speachy [0] (~speachy@rockbox/developer/speachy) 10.02.06 Mode "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) 10.05.43 # fun factoid: A full set of dailies now takes up 5.3GB. 10.06.16 # (adding the two ES voices brought it up from ~4.9GB) 10.34.54 *** Saving seen data "./dancer.seen" 10.37.54 Quit jacobk (Ping timeout: 248 seconds) 10.51.46 Join jacobk [0] (~quassel@2603:8080:b200:7b02::b71) 10.56.05 # speachy: do you what happened with the Meizu ports (M3, M6SL and M6SP), and the Samsung YP-S3 port? 10.56.31 # they are all based on S5L8700 and they don't build at the moment 10.57.52 Quit chris_s (Quit: Client closed) 10.58.48 Join chris_s [0] (~chris_s@2a09:bac2:281c:1282::1d8:2c) 11.11.44 # ... probably just bitrot. AFAIK they were never even consisdered "unusable" 11.12.23 Join Natch [0] (~natch@c-92-34-7-158.bbcust.telenor.se) 11.12.37 # yean: https://www.rockbox.org/wiki/MeizuM6Port 11.14.27 Quit chris_s (Quit: Client closed) 11.14.29 Join chris_s57 [0] (~chris_s@2a09:bac2:2bcf:2482::3a3:2d) 11.15.49 Quit Everything (Quit: leaving) 11.22.18 Quit chris_s57 (Quit: Client closed) 11.22.45 Join chris_s [0] (~chris_s@2a09:bac2:2bcf:2482::3a3:2d) 12.34.55 *** Saving seen data "./dancer.seen" 12.57.50 Quit jacobk (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 13.16.46 Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) 13.19.30 Join WebGuest5 [0] (~WebGuest5@172.58.51.93) 13.20.14 # Hello, what does the latest dev releases mean for iPod 5.5g? Is that the video decoder chip? 13.20.34 Quit advcomp2019__ (Ping timeout: 248 seconds) 13.21.03 Quit WebGuest5 (Client Quit) 13.32.38 # nope, zero support for the video decoder chip, and that's not likely to ever change. 14.00.27 Quit chris_s (Quit: Client closed) 14.29.39 Join jacobk [0] (~quassel@2603:8080:b200:7b02::b71) 14.34.56 *** Saving seen data "./dancer.seen" 14.56.04 Join WebGuest80 [0] (~WebGuest8@lcs06-lyo-176-188-173-96.sfr.lns.abo.bbox.fr) 14.56.07 # hello world 14.58.18 # his the Aigo MP3-105 PLUS one of those rockbox supported device? 14.58.27 # His/is 14.59.20 # Trying to pick a new rockbox device, and those chineses devices not that easy to differentiate 15.00.55 # If someone can please answer, i will check the logs and will try to find a good android irc client 15.01.14 Quit WebGuest80 (Quit: Client closed) 15.04.58 # Is that on the list of "supported devices" at www.rockbox.org? 15.05.17 # if it is, then it's supported. if it's not, then it isn't. 15.15.13 Join WebGuest5 [0] (~WebGuest5@2605:59c8:40a0:414:8453:4fd6:c811:ec97) 15.15.51 # Is that because there is no one to work on it, or it is just difficult? 15.15.57 Quit WebGuest5 (Client Quit) 15.31.24 # no documetnation and it's of questionable utility anyway. 15.32.30 # nobody active cares about it. 15.34.10 # The hardware is over years old at this point, will never support modern video codecs, and even teh crappiest phone these days will do a vastly better job. 15.35.57 # over 19 years, that is. 15.42.21 Join chris_s [0] (~chris_s@2a09:bac2:2de2:246e::3a1:72) 15.47.06 Join Everything [0] (~Everythin@46.211.115.170) 16.00.38 # but if someone wants to work on it and succeeds in making it work, I see no inherent reason why it can't be merged in. 16.14.29 Quit jacobk (Ping timeout: 260 seconds) 16.22.33 Quit Everything (Quit: leaving) 16.26.05 Join Everything [0] (~Everythin@46.211.115.170) 16.28.27 Join jacobk [0] (~quassel@47-186-65-73.dlls.tx.frontiernet.net) 16.35.00 *** Saving seen data "./dancer.seen" 17.19.20 # Build Server message: 3New build round started. Revision 1535a42b68, 345 builds, 9 clients. 17.19.20 # 3Add include guard to s5l8700.h by Vencislav Atanasov 17.30.15 Quit chris_s (Quit: Client closed) 17.31.47 Join chris_s [0] (~chris_s@2a09:bac2:2d60:18fa::27d:7d) 17.34.39 # Build Server message: 3Build round completed after 919 seconds. 17.34.40 # Build Server message: 3Revision 1535a42b68 result: All green 17.50.00 Join yang4 [0] (uid23779@id-23779.lymington.irccloud.com) 18.11.00 # bilgus: 2591f6a is crashing for me on device when changing themes while music is playing/paused 18.18.30 # read_color_theme_file probably shouldn't have an INIT_ATTR 18.35.01 *** Saving seen data "./dancer.seen" 18.44.13 # Build Server message: 3New build round started. Revision 237c83852a, 345 builds, 9 clients. 18.44.13 # 3Fix: read_color_theme_file needed beyond init by Christian Soffke 18.45.39 # hope you don't mind :) 18.58.35 # Build Server message: 3Build round completed after 863 seconds. 18.58.36 # Build Server message: 3Revision 237c83852a result: All green 19.10.09 Quit jacobk (Ping timeout: 276 seconds) 19.10.42 Join jacobk [0] (~quassel@47-186-65-73.dlls.tx.frontiernet.net) 19.16.13 Quit Everything (Quit: leaving) 19.28.19 Join othello8 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) 19.29.42 # <_bilgus> no worries thanks! 19.31.12 # <_bilgus> well that explains the exter 200 bytes I was seeing 19.31.29 # yeah, sorry :D 19.32.55 # still a net "positive" (negative) 19.37.07 Quit lebellium (Quit: Leaving) 19.41.31 # Build Server message: 3New build round started. Revision 75a4937568, 345 builds, 9 clients. 19.41.32 # 3skin_tags save space in tag_table by William Wilgus 19.42.34 # <_bilgus> I think I was expecting 160 the 400 was a bit suprising but I didn't see anything 'wrong' in the code thats ok though I have another 500 or so to make up for it 19.42.59 # heh :) 19.55.10 Quit yang4 (Quit: Connection closed for inactivity) 19.55.19 # Build Server message: 3Build round completed after 828 seconds. 19.55.20 # Build Server message: 3Revision 75a4937568 result: 0 errors 217 warnings 20.13.35 # <_bilgus> strange I didn't see that warning when I tried this on the sim 20.22.31 # Build Server message: 3New build round started. Revision 213686b55c, 345 builds, 9 clients. 20.22.31 # 3[Fix Yellow] skin_parser.c const correctness by William Wilgus 20.24.16 Quit chris_s (Quit: Client closed) 20.27.20 Join massiveH [0] (~massiveH@2600:4040:a982:5400:dcb4:5165:4147:c1b7) 20.35.04 *** Saving seen data "./dancer.seen" 20.36.13 # Build Server message: 3Build round completed after 823 seconds. 20.36.14 # Build Server message: 3Revision 213686b55c result: All green 20.36.22 # Build Server message: 3New build round started. Revision a41a001258, 345 builds, 9 clients. 20.36.22 # 3info_menu: Don't print a line for volumes that don't exist by Solomon Peachy 20.37.53 # <_bilgus> ^ CHECK_VOL(i) ^ I was wondering about that.. 20.38.45 Quit MarcAndersen (Quit: I was using NightOwl 0.2.) 20.39.33 Quit speachy (Quit: WeeChat 4.4.3) 20.39.46 Join speachy [0] (~speachy@rockbox/developer/speachy) 20.39.46 Mode "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) 20.40.05 # _bilgus: it actually #defines to be the same thing in the end, but I wanted to be consistent. 20.40.22 # (all of the uses are already within #ifdef HAVE_MULTIVOLUME anyway. 20.41.01 # the actual meat was making sure that we didn't try to display an uninitialized entry. 20.41.31 # and I special-cased logic to ensure that multidrive targets that have the secondary drive not present still show a line. 20.43.35 # this has been broken for a while ( and was actually mentioned in comments) but I completely forgot about it. An unrelated changed caused the garbage volume name output, figured I should fix both at once. 20.44.50 # one remaining problem is that all volumes on the same drive get the same "name" string. That should probably get fixed. 20.46.07 # btw, _bilgus, it's interesitn how your last commit was smaller on arm targets but larger on mips and m68k 20.46.38 Quit othello8 (Quit: othello8) 20.47.27 # also that INIT_ATTR stuff would have been automatically caught (and failed) with GCC8+ 20.48.36 # Build Server message: 3Build round completed after 735 seconds. 20.48.38 # Build Server message: 3Revision a41a001258 result: 45 errors 28 warnings 20.48.41 # <_bilgus> yeah I saw that and I'm wondering why that would be the case unless somehow it doesn't like the alignment now 20.48.51 # yeah, that's what I was thinking 20.48.55 # lovely.. 20.48.59 # <_bilgus> either that or itll bounce back later 20.49.38 # <_bilgus> see if I have a cross compiler set up and move soem elems around 20.51.32 # well, you do have an enum(ie int)/short/char*/int which is ...awkward. 20.51.45 # in struct tag_info 20.52.01 # <_bilgus> well you know on arm that enum is an int or a short 20.52.40 # <_bilgus> I bet the mips defaults to 4byte int and now its throwing an extra 2 bytes 20.52.50 # (I thought enums were always ints?) 20.53.35 # <_bilgus> me too but when I started doing sizeof it spits back 2 20.54.14 # <_bilgus> I should be able to remove the enum and just put another ushort and see if it drops 20.54.26 # but you went from enum/char*/char* so that shouldn't have mattered. 20.56.21 # <_bilgus> sure enough 20.57.47 # <_bilgus> drops 768 bytes 20.58.01 # ouch.. 20.59.46 # Build Server message: 3New build round started. Revision 57cd8cd712, 345 builds, 9 clients. 20.59.47 # 3fix warnings and errors in a41a001258 by Solomon Peachy 21.01.02 # btw, the build_firstletter_menu() triggers GCC9 warnings about string overflows. 21.04.09 # these buils are helping keep my house warm 21.04.13 # <_bilgus> my guess would be it doesn't like strlen+1 or buf[1] = 'A'+1 pretty simple fn though 21.06.41 # <_bilgus> the latter would be my suspicion though since we don't check sprintf it might terminate at index [0] and we just overwrote it with a letter 21.06.53 # https://www.shaftnet.org/~pizza/foo.txt 21.07.15 # I have -Werror turned on on many of my trees here 21.09.26 # <_bilgus> seems specious 21.09.41 # I didn't look into it in any detail 21.10.02 # <_bilgus> truncation would be expected 21.11.03 # <_bilgus> its pretty much what I alluded to up there probably check for the truncation will shut it up 21.11.13 # <_bilgus> or at least make sure its > 1 21.13.32 # Build Server message: 3Build round completed after 826 seconds. 21.13.33 # Build Server message: 3Revision 57cd8cd712 result: 25 errors 3 warnings 21.14.45 # <_bilgus> I hate touching this stuff that has all these ifdefs everwhere it always looks like this^ 21.17.13 # ugh, missed the fact that the current error targets don't use the generic system-hosted.c 21.19.27 # <_bilgus> for BFL- I guess the proper thing to do would be check if sprintf exceeded and if so dump that line (i suspect that would be the same as just returning) 21.19.54 # <_bilgus> ... since they are the same except for the letter 21.22.01 # Build Server message: 3New build round started. Revision 21ebfd574a, 345 builds, 9 clients. 21.22.01 # 3fix more red in hosted targets that don't share the generic system implementation by Solomon Peachy 21.22.13 # need to refactor this stuff some more, sigh. 21.27.51 # that #ifdef craziness in the info menu's refresh_data() function is there so we don't need four different versions. 21.36.47 # <_bilgus> we have something like 190 SKIN_TOKEN enums 21.36.59 # Build Server message: 3Build round completed after 899 seconds. 21.37.01 # Build Server message: 3Revision 21ebfd574a result: 0 errors 3 warnings 21.37.36 # <_bilgus> It makes me wonder if we had (had) a better language if it might offset the storage requirements lol 21.37.50 # <_bilgus> nice down to warnings now 21.42.34 # that's odd. 21.44.06 # Build Server message: 3New build round started. Revision 1bf19eaaff, 345 builds, 9 clients. 21.44.06 # 3tag_table use unsigned short rather than enum by William Wilgus 21.52.04 # <_bilgus> you know I that ARM 2byte ENUM might explain some weird things here and there 21.52.54 # <_bilgus> should look and see if theres any with > 16 bits worth of flags 21.59.57 # Build Server message: 3Build round completed after 953 seconds. 21.59.59 # Build Server message: 3Revision 1bf19eaaff result: 0 errors 3 warnings 22.03.09 # <_bilgus> so why it added 4bytes of padding to that struct IDK 22.04.12 # <_bilgus> maybe its got weird alignment requirements for strings 22.04.22 # <_bilgus> seems odd 22.12.25 # <_bilgus> recorder/recording.c is the first enum I see using bug numbers 0x0000000n though I think that will be converted fine 22.13.21 Join rnkn [0] (~rnkn@2001:8004:4441:7b53:d70:d11:8629:e9b5) 22.15.14 # the sim warnings are odd. haven't figured out why those three are special 22.18.30 # ie why those tthree, but not the other two IHIFI ones that have no meaningful differences in their configs. 22.19.12 Join hook54321 [0] (sid149355@user/hook54321) 22.27.22 # there doesn't seem to be any crash logs? 22.30.46 # in what context? 22.31.30 # _bilgus: can you try the latest dev build on a sansa (with or without an sd card present) and tell me what shows up in the about/rockbox info for the disks? 22.34.27 # <_bilgus> Int:3.4GB... HD1: 22.34.38 # <_bilgus> its free and total sz as well 22.34.41 # oh good, they both show up properly. 22.34.59 # speachy: when I get a freeze I'd like to be able to provide some feedback as to its cause 22.35.05 *** Saving seen data "./dancer.seen" 22.35.18 # <_bilgus> w/O sd card it says the same but HD1: Not present 22.36.26 # you can do custom builds with logging that has to be selectively enabled, but we don't have the raw resources for true telemetry gathering. plus there's the whole problem of storing it safely if there is a crash. 22.36.49 # but freezes aren't crashes, so.. 22.37.22 # if there's a panic (ie we actually catch it happening) a screen's worth of the most recent log messages are shown. 22.38.34 # ah I see, yes I've had a couple of panics, but mostly I'm getting freezes, i.e. unresponsive, needs hard reset 22.38.42 # I'm on the dev build 22.39.15 # which build specifically, which target (and any mods), etc? 22.39.42 # Build Server message: 3New build round started. Revision fb2316b9b0, 345 builds, 9 clients. 22.39.42 # 3Hopfully fix up the remaining warnings by Solomon Peachy 22.41.10 # I think build 20241114 (can I check this somewhere in /.rockbox ?) and iPod 5th gen Video 22.41.28 # I'll update to the latest build to be sure 22.41.41 # rockbox-info.txt 22.43.10 # I'd expect 20241116 to behave quite differently. 22.43.31 # d36ef610c2-241114 22.43.35 # okay cool 22.43.37 # in the future, please update to the absolute latest before doing a bug report. 22.43.44 # sweet, okay 22.43.47 # will do 22.44.01 # since "dev build" changes after every commit and "daily build" changes every day... 22.44.14 # that includes forum posts? 22.47.48 # goes for _any_ report. incouing the build ID, target, and any mods are essential, and saves having to respond with questions 22.48.25 # most of the time forum posts contain next to no actionable information 22.49.25 # there's also the possibility that you have disk corruption that needs to be checked for and/or fixed (ie via chkdsk/fsck) 22.52.21 # Build Server message: 3Build round completed after 760 seconds. 22.52.23 # Build Server message: 3Revision fb2316b9b0 result: 118 errors 0 warnings 22.52.38 # _bilgus: btw I highly recommend using the Advanced/Errors on Warnings. 22.52.52 # aaand I made things a lot worse, apparently. sigh. 22.53.59 # this time I broke everytihng that was !(MULTIDRIVE|MULTIVOLUME) 22.54.19 # <_bilgus> Advances/Errors on warnings in regards to? 22.54.47 # turns on -Werror, would have caught that "warning on every target" line on the build wall 22.58.09 # _bilgus: have a look at https://forums.rockbox.org/index.php/topic,55121.msg254743.html#msg254743 22.58.53 # are config file options case-sensitive? 22.59.29 # not sure why this is only triggered on the ipod6g; might have to do with the virtual sector size of 4K but 512B storage sector size. 22.59.53 # rnkn: generally yes 23.00.57 Join advcomp2019 [0] (~advcomp20@user/advcomp2019) 23.01.00 Quit advcomp2019_ (Ping timeout: 252 seconds) 23.01.35 # cool, ty just checking the difference between the lastfm_scrobbler plugin and Last.fm_logging config option 23.07.17 # Build Server message: 3New build round started. Revision 7df324b819, 345 builds, 9 clients. 23.07.17 # 3sdmmc: the tCardInfo.initialized field needs to be an integer, not bool by Solomon Peachy 23.08.03 # whoops, didn't mean to push that with the latest build fixes. but it was an interesting find nonetheless. 23.08.03 # okay seems like Last.fm_logging has no effect 23.12.40 # <_bilgus> in what way? are you waiting till a track is 1/2 done? haveyou tried rerunning and manually flushing? 23.13.30 # <_bilgus> speachy Re the forum so they didn't have the proper lang file then? 23.14.23 # <_bilgus> I mean if you had the wrong version it would mostly work 23.15.50 # _bilgus the plugin works like a charm (i.e. logged to /.scrobbler.log at 50% of track playback), I just saw the config option listed in the manual and figured I might be able to get the same result without having the plugin running 23.16.27 # it appears that loading a non-builtin lang is what triggers the problem 23.16.45 # <_bilgus> no it used to be in core this is no longer the case unless I get a scriptin language in core at some point 23.17.31 # <_bilgus> speachy so losing an index then sounds weird 23.18.16 # <_bilgus> unless something isn't getting freed or something 23.18.57 # only seems to be triggered on the ipod6g, and started when I dropped SECTOR_SIZE from 4096 to 512 23.19.13 # (and turned on use of the MAX_PHYS_SECTOR_SIZE mechanism instead) 23.19.17 # ah I see, so it went from core to pluging, I assumed it would go the other way 23.20.24 # Build Server message: 3Build round completed after 788 seconds. 23.20.25 # Build Server message: 3Revision 7df324b819 result: All green 23.20.35 # huzzah 23.21.05 # <_bilgus> rnkn most of the info is contained in the playlist control file at some point i may just make a way to parse it into a scrobbler too 23.21.37 # <_bilgus> only thing missing is the played length part 23.22.30 # <_bilgus> TBH though I really don't have any skin need someone who cares about it, I was just trying to be nice by not removing it completely 23.23.40 # I wouldn't mind about losing the 50% playback threshold if it meant scrobbling didn't need a plugin always running 23.23.53 # do you mean you are no longer scrobbling, hence no skin? 23.24.07 # <_bilgus> I never did 23.24.32 # <_bilgus> but yeah.. 23.25.54 # then that is a very generous way to spend your time, much gratitude 23.26.54 # aha, I think I found the underliyng issue. 23.28.43 # the file I/O code works in terms of the _filesystem_ logical sector size, but the underlying filestr_cache stuff uses dc_get_buffer() which is defined in terms of SECTOR_SIZE 23.28.49 # ewwwwww. 23.29.00 # so we're overflowing the DC cache. 23.29.07 # ...badly. 23.31.10 # <_bilgus> man that stuff is Hairy wish sevakis JHMIKES was around 23.32.13 # the thing is this has probably been subtly broken for quite some time 23.32.45 # on anything that uses larger "virtual" sector sizes than the underlying storage device's logical sector size 23.33.02 # <_bilgus> yeah ass u mptions 23.33.06 # the two prime examples are the ipod 5g ang 6g. 23.34.04 # the 5g uses 2K virtual sectors, 6g 4K 23.34.31 # (which incidentally means they could end up with much larger than 2TiB paritions!) 23.35.28 # the 6G just had a hardcoded SECTOR_SIZE of 4K, and shenanigans in its custom ATA driver to map that back to 512B sector drives. 23.36.49 # the 6G needed to work with either 512 or 2K sectors depending on the model. but this means that for the 2K sectored devices (which I think is all the 5.5g stuff) we've been trashing our disk cache buffers. 23.37.07 # we _may_ have some readahead going on which would have partially mitigated this, but... 23.37.13 # bah 23.40.19 Quit akaWolf (Ping timeout: 272 seconds) 23.45.04 Join akaWolf [0] (~akaWolf@akawolf.org) 23.57.08 Quit akaWolf (Ping timeout: 255 seconds)