| 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:00 |
| 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:00 |
| 02:10:55 | | Quit massiveH (Read error: Connection reset by peer) |
| 02:34:44 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 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:00 |
| 06:34:46 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:21:33 | | Quit Natch (Remote host closed the connection) |
| 08:34:50 | *** | Saving seen data "./dancer.seen" |
| 08:42:53 | user890104 | 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:00 |
| 09:02:52 | | Join chris_s [0] (~chris_s@2a09:bac2:2b74:2464::3a0:12) |
| 09:05:41 | rb-bluebot | Build Server message: New build round started. Revision 46a4361bf1, 345 builds, 9 clients. |
| 09:05:42 | rb-bluebot | playlist viewer: move on-disk playlist struct to playlist.c by Christian Soffke |
| 09:21:51 | rb-bluebot | Build Server message: Build round completed after 970 seconds. |
| 09:21:53 | rb-bluebot | Build Server message: Revision 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:00 |
| 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 | speachy | fun factoid: A full set of dailies now takes up 5.3GB. |
| 10:06:16 | speachy | (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 | user890104 | speachy: do you what happened with the Meizu ports (M3, M6SL and M6SP), and the Samsung YP-S3 port? |
| 10:56:31 | user890104 | 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:00 |
| 11:11:44 | speachy | ... 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 | speachy | 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:00 |
| 12:34:55 | *** | Saving seen data "./dancer.seen" |
| 12:57:50 | | Quit jacobk (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 13:00 |
| 13:16:46 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 13:19:30 | | Join WebGuest5 [0] (~WebGuest5@172.58.51.93) |
| 13:20:14 | WebGuest5 | 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 | speachy | nope, zero support for the video decoder chip, and that's not likely to ever change. |
| 14:00 |
| 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 | WebGuest80 | hello world |
| 14:58:18 | WebGuest80 | his the Aigo MP3-105 PLUS one of those rockbox supported device? |
| 14:58:27 | WebGuest80 | His/is |
| 14:59:20 | WebGuest80 | Trying to pick a new rockbox device, and those chineses devices not that easy to differentiate |
| 15:00 |
| 15:00:55 | WebGuest80 | 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 | speachy | Is that on the list of "supported devices" at www.rockbox.org? |
| 15:05:17 | speachy | 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 | WebGuest5 | 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 | speachy | no documetnation and it's of questionable utility anyway. |
| 15:32:30 | speachy | nobody active cares about it. |
| 15:34:10 | speachy | 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 | speachy | 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 |
| 16:00:38 | speachy | 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:00 |
| 17:19:20 | rb-bluebot | Build Server message: New build round started. Revision 1535a42b68, 345 builds, 9 clients. |
| 17:19:20 | rb-bluebot | Add 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 | rb-bluebot | Build Server message: Build round completed after 919 seconds. |
| 17:34:40 | rb-bluebot | Build Server message: Revision 1535a42b68 result: All green |
| 17:50:00 | | Join yang4 [0] (uid23779@id-23779.lymington.irccloud.com) |
| 18:00 |
| 18:11:00 | chris_s | bilgus: 2591f6a is crashing for me on device when changing themes while music is playing/paused |
| 18:18:30 | chris_s | read_color_theme_file probably shouldn't have an INIT_ATTR |
| 18:35:01 | *** | Saving seen data "./dancer.seen" |
| 18:44:13 | rb-bluebot | Build Server message: New build round started. Revision 237c83852a, 345 builds, 9 clients. |
| 18:44:13 | rb-bluebot | Fix: read_color_theme_file needed beyond init by Christian Soffke |
| 18:45:39 | chris_s | hope you don't mind :) |
| 18:58:35 | rb-bluebot | Build Server message: Build round completed after 863 seconds. |
| 18:58:36 | rb-bluebot | Build Server message: Revision 237c83852a result: All green |
| 19:00 |
| 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 | chris_s | yeah, sorry :D |
| 19:32:55 | chris_s | still a net "positive" (negative) |
| 19:37:07 | | Quit lebellium (Quit: Leaving) |
| 19:41:31 | rb-bluebot | Build Server message: New build round started. Revision 75a4937568, 345 builds, 9 clients. |
| 19:41:32 | rb-bluebot | skin_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 | chris_s | heh :) |
| 19:55:10 | | Quit yang4 (Quit: Connection closed for inactivity) |
| 19:55:19 | rb-bluebot | Build Server message: Build round completed after 828 seconds. |
| 19:55:20 | rb-bluebot | Build Server message: Revision 75a4937568 result: 0 errors 217 warnings |
| 20:00 |
| 20:13:35 | _bilgus | strange I didn't see that warning when I tried this on the sim |
| 20:22:31 | rb-bluebot | Build Server message: New build round started. Revision 213686b55c, 345 builds, 9 clients. |
| 20:22:31 | rb-bluebot | [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 | rb-bluebot | Build Server message: Build round completed after 823 seconds. |
| 20:36:14 | rb-bluebot | Build Server message: Revision 213686b55c result: All green |
| 20:36:22 | rb-bluebot | Build Server message: New build round started. Revision a41a001258, 345 builds, 9 clients. |
| 20:36:22 | rb-bluebot | info_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 | speachy | _bilgus: it actually #defines to be the same thing in the end, but I wanted to be consistent. |
| 20:40:22 | speachy | (all of the uses are already within #ifdef HAVE_MULTIVOLUME anyway. |
| 20:41:01 | speachy | the actual meat was making sure that we didn't try to display an uninitialized entry. |
| 20:41:31 | speachy | and I special-cased logic to ensure that multidrive targets that have the secondary drive not present still show a line. |
| 20:43:35 | speachy | 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 | speachy | one remaining problem is that all volumes on the same drive get the same "name" string. That should probably get fixed. |
| 20:46:07 | speachy | 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 | speachy | also that INIT_ATTR stuff would have been automatically caught (and failed) with GCC8+ |
| 20:48:36 | rb-bluebot | Build Server message: Build round completed after 735 seconds. |
| 20:48:38 | rb-bluebot | Build Server message: Revision 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 | speachy | yeah, that's what I was thinking |
| 20:48:55 | speachy | 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 | speachy | well, you do have an enum(ie int)/short/char*/int which is ...awkward. |
| 20:51:45 | speachy | 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 | speachy | (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 | speachy | 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 | speachy | ouch.. |
| 20:59:46 | rb-bluebot | Build Server message: New build round started. Revision 57cd8cd712, 345 builds, 9 clients. |
| 20:59:47 | rb-bluebot | fix warnings and errors in a41a001258 by Solomon Peachy |
| 21:00 |
| 21:01:02 | speachy | btw, the build_firstletter_menu() triggers GCC9 warnings about string overflows. |
| 21:04:09 | speachy | 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 | speachy | https://www.shaftnet.org/~pizza/foo.txt |
| 21:07:15 | speachy | I have -Werror turned on on many of my trees here |
| 21:09:26 | _bilgus | seems specious |
| 21:09:41 | speachy | 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 | rb-bluebot | Build Server message: Build round completed after 826 seconds. |
| 21:13:33 | rb-bluebot | Build Server message: Revision 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 | speachy | 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 | rb-bluebot | Build Server message: New build round started. Revision 21ebfd574a, 345 builds, 9 clients. |
| 21:22:01 | rb-bluebot | fix more red in hosted targets that don't share the generic system implementation by Solomon Peachy |
| 21:22:13 | speachy | need to refactor this stuff some more, sigh. |
| 21:27:51 | speachy | 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 | rb-bluebot | Build Server message: Build round completed after 899 seconds. |
| 21:37:01 | rb-bluebot | Build Server message: Revision 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 | speachy | that's odd. |
| 21:44:06 | rb-bluebot | Build Server message: New build round started. Revision 1bf19eaaff, 345 builds, 9 clients. |
| 21:44:06 | rb-bluebot | tag_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 | rb-bluebot | Build Server message: Build round completed after 953 seconds. |
| 21:59:59 | rb-bluebot | Build Server message: Revision 1bf19eaaff result: 0 errors 3 warnings |
| 22:00 |
| 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 | speachy | the sim warnings are odd. haven't figured out why those three are special |
| 22:18:30 | speachy | 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 | rnkn | there doesn't seem to be any crash logs? |
| 22:30:46 | speachy | in what context? |
| 22:31:30 | speachy | _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 | speachy | oh good, they both show up properly. |
| 22:34:59 | rnkn | 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 | speachy | 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 | speachy | but freezes aren't crashes, so.. |
| 22:37:22 | speachy | 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 | rnkn | 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 | rnkn | I'm on the dev build |
| 22:39:15 | speachy | which build specifically, which target (and any mods), etc? |
| 22:39:42 | rb-bluebot | Build Server message: New build round started. Revision fb2316b9b0, 345 builds, 9 clients. |
| 22:39:42 | rb-bluebot | Hopfully fix up the remaining warnings by Solomon Peachy |
| 22:41:10 | rnkn | I think build 20241114 (can I check this somewhere in /.rockbox ?) and iPod 5th gen Video |
| 22:41:28 | rnkn | I'll update to the latest build to be sure |
| 22:41:41 | speachy | rockbox-info.txt |
| 22:43:10 | speachy | I'd expect 20241116 to behave quite differently. |
| 22:43:31 | rnkn | d36ef610c2-241114 |
| 22:43:35 | rnkn | okay cool |
| 22:43:37 | speachy | in the future, please update to the absolute latest before doing a bug report. |
| 22:43:44 | rnkn | sweet, okay |
| 22:43:47 | rnkn | will do |
| 22:44:01 | speachy | since "dev build" changes after every commit and "daily build" changes every day... |
| 22:44:14 | rnkn | that includes forum posts? |
| 22:47:48 | speachy | goes for _any_ report. incouing the build ID, target, and any mods are essential, and saves having to respond with questions |
| 22:48:25 | speachy | most of the time forum posts contain next to no actionable information |
| 22:49:25 | speachy | 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 | rb-bluebot | Build Server message: Build round completed after 760 seconds. |
| 22:52:23 | rb-bluebot | Build Server message: Revision fb2316b9b0 result: 118 errors 0 warnings |
| 22:52:38 | speachy | _bilgus: btw I highly recommend using the Advanced/Errors on Warnings. |
| 22:52:52 | speachy | aaand I made things a lot worse, apparently. sigh. |
| 22:53:59 | speachy | this time I broke everytihng that was !(MULTIDRIVE|MULTIVOLUME) |
| 22:54:19 | _bilgus | Advances/Errors on warnings in regards to? |
| 22:54:47 | speachy | turns on -Werror, would have caught that "warning on every target" line on the build wall |
| 22:58:09 | speachy | _bilgus: have a look at https://forums.rockbox.org/index.php/topic,55121.msg254743.html#msg254743 |
| 22:58:53 | rnkn | are config file options case-sensitive? |
| 22:59:29 | speachy | 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 | speachy | rnkn: generally yes |
| 23:00 |
| 23:00:57 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 23:01:00 | | Quit advcomp2019_ (Ping timeout: 252 seconds) |
| 23:01:35 | rnkn | cool, ty just checking the difference between the lastfm_scrobbler plugin and Last.fm_logging config option |
| 23:07:17 | rb-bluebot | Build Server message: New build round started. Revision 7df324b819, 345 builds, 9 clients. |
| 23:07:17 | rb-bluebot | sdmmc: the tCardInfo.initialized field needs to be an integer, not bool by Solomon Peachy |
| 23:08:03 | speachy | whoops, didn't mean to push that with the latest build fixes. but it was an interesting find nonetheless. |
| 23:08:03 | rnkn | 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 | rnkn | _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 | speachy | 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 | speachy | only seems to be triggered on the ipod6g, and started when I dropped SECTOR_SIZE from 4096 to 512 |
| 23:19:13 | speachy | (and turned on use of the MAX_PHYS_SECTOR_SIZE mechanism instead) |
| 23:19:17 | rnkn | ah I see, so it went from core to pluging, I assumed it would go the other way |
| 23:20:24 | rb-bluebot | Build Server message: Build round completed after 788 seconds. |
| 23:20:25 | rb-bluebot | Build Server message: Revision 7df324b819 result: All green |
| 23:20:35 | speachy | 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 | rnkn | I wouldn't mind about losing the 50% playback threshold if it meant scrobbling didn't need a plugin always running |
| 23:23:53 | rnkn | 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 | rnkn | then that is a very generous way to spend your time, much gratitude |
| 23:26:54 | speachy | aha, I think I found the underliyng issue. |
| 23:28:43 | speachy | 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 | speachy | ewwwwww. |
| 23:29:00 | speachy | so we're overflowing the DC cache. |
| 23:29:07 | speachy | ...badly. |
| 23:31:10 | _bilgus | man that stuff is Hairy wish sevakis JHMIKES was around |
| 23:32:13 | speachy | the thing is this has probably been subtly broken for quite some time |
| 23:32:45 | speachy | 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 | speachy | the two prime examples are the ipod 5g ang 6g. |
| 23:34:04 | speachy | the 5g uses 2K virtual sectors, 6g 4K |
| 23:34:31 | speachy | (which incidentally means they could end up with much larger than 2TiB paritions!) |
| 23:35:28 | speachy | 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 | speachy | 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 | speachy | we _may_ have some readahead going on which would have partially mitigated this, but... |
| 23:37:13 | speachy | 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) |
icon identifies that the person is a core developer (has commit access).