| 01:00 |
| 01:29:05 | _bilgus_ | ok thats background bmp files |
| 01:32:44 | _bilgus_ | I calculate my tagtree is using 210904 bytes the other allocs come up to 115424 all of that except 64k of that would need to be free to satisfy this so wtf did we change something recently? |
| 01:37:18 | *** | No seen item changed, no save performed. |
| 01:41:02 | | Join advcomp2019__ [0] (~advcomp20@user/advcomp2019) |
| 01:44:44 | | Quit advcomp2019_ (Ping timeout: 272 seconds) |
| 02:00 |
| 02:15:39 | _bilgus_ | Hmm it looks to me that its a direct result of all these audio clips getting loaded and this commit |
| 02:15:41 | _bilgus_ | https://github.com/Rockbox/rockbox/commit/af02a674c539ee76260be543c000637ffa6ce2af |
| 02:16:41 | _bilgus_ | so What I can do I think I make that for targets with 8 or fewer mb |
| 03:00 |
| 03:09:41 | _bilgus_ | at the moment the voice file is 253 ish kb its taking over the playback buffer but why isn't it getting shrunk/freed? |
| 03:10:43 | _bilgus_ | and the answer is that we weren't checking well enough if we should free the talk buffer before the alloc and the 253kb voice file stays loaded |
| 03:21:41 | _bilgus_ | g#5944 |
| 03:21:44 | rb-bluebot | Gerrit review #5944 at https://gerrit.rockbox.org/r/c/rockbox/+/5944 : [BugFix] Playback.c OOM with large voice file by William Wilgus |
| 03:37:20 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:04:19 | | Quit jacobk (Ping timeout: 260 seconds) |
| 05:05:29 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 05:37:23 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:07:32 | | Quit PheralSparky (Read error: Connection reset by peer) |
| 07:00 |
| 07:37:24 | *** | Saving seen data "./dancer.seen" |
| 07:44:41 | rb-bluebot | Build Server message: New build round started. Revision 56bd6cd634, 345 builds, 9 clients. |
| 07:44:41 | rb-bluebot | fonts: 12-Adobe-Helvetica.bdf: adjust width for few letters by Roman Artiukhin |
| 08:00 |
| 08:00:03 | rb-bluebot | Build Server message: Build round completed after 924 seconds. |
| 08:00:05 | rb-bluebot | Build Server message: Revision 56bd6cd634 result: All green |
| 08:59:23 | speachy | _bilgus_: that's a bit of a d'oh. any reason to not merge it? |
| 09:00 |
| 09:37:28 | *** | No seen item changed, no save performed. |
| 09:43:24 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 10:00 |
| 10:27:51 | rb-bluebot | Build Server message: New build round started. Revision c3f51b5fe9, 345 builds, 9 clients. |
| 10:27:52 | rb-bluebot | opus: Re-add a ICONST_ATTR lost in 4c6bb798d6bebc80f07e863236adbaf8d156a9c by Solomon Peachy |
| 10:33:30 | speachy | don't think that will move the needle much but it can't hurt. |
| 10:33:43 | speachy | really need a coldfire device to run benchmarks on |
| 10:42:04 | rb-bluebot | Build Server message: Build round completed after 853 seconds. |
| 10:42:05 | rb-bluebot | Build Server message: Revision c3f51b5fe9 result: All green |
| 10:45:25 | _bilgus_ | no other than I didn't want to sit and wait for it to finish |
| 10:47:36 | rb-bluebot | Build Server message: New build round started. Revision f0c208554c, 345 builds, 9 clients. |
| 10:47:37 | rb-bluebot | [BugFix] Playback.c OOM with large voice file by William Wilgus |
| 10:56:26 | _bilgus_ | I was going to go and say maybe we need to split out the voice file but it looks like since it was built with 2mb devices in mind most of the provisions are there for it to be say 1MB |
| 10:57:01 | _bilgus_ | but its probably already too much for the 2mb clip |
| 10:57:26 | _bilgus_ | not fixing it there if so |
| 11:00 |
| 11:01:29 | rb-bluebot | Build Server message: Build round completed after 834 seconds. |
| 11:01:31 | rb-bluebot | Build Server message: Revision f0c208554c result: All green |
| 11:01:38 | rb-bluebot | Build Server message: New build round started. Revision 5d2692375d, 345 builds, 9 clients. |
| 11:01:38 | rb-bluebot | rbutil: Add erosqnative by Dana Conrad |
| 11:08:32 | | Quit dconrad (Remote host closed the connection) |
| 11:13:49 | rb-bluebot | Build Server message: Build round completed after 733 seconds. |
| 11:13:51 | rb-bluebot | Build Server message: Revision 5d2692375d result: All green |
| 11:14:01 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 11:18:42 | | Quit dconrad (Ping timeout: 248 seconds) |
| 11:28:45 | _bilgus_ | so that should fix the major issues I did note the voice changes pitch after playback has been started in the sim wonder if thats a sign of something else |
| 11:28:48 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 11:31:51 | speachy | sample rate difference? |
| 11:37:29 | *** | Saving seen data "./dancer.seen" |
| 11:47:33 | _bilgus_ | I'm hoping thats all it is |
| 11:56:43 | _bilgus_ | the crash on device still appears to be there |
| 11:57:28 | _bilgus_ | voice enable and go to browse the db 'buflib error' invalid_handle_pin -2 |
| 11:57:51 | _bilgus_ | guess I'll start tracking that down this eve |
| 11:58:41 | _bilgus_ | ok files too |
| 12:00 |
| 12:02:20 | _bilgus_ | disabling voice fixes it, this one is probably going to be a bit harder to find. Its crashing in the shrink function so, I'll have to first figure out which alloc it is |
| 12:20:13 | speachy | Hmm, the shuffle rewrite exacerbated it? |
| 12:23:39 | _bilgus_ | Idk yet probably could bisect if I get stuck but I'm guessing memory pressure is just exposing something |
| 12:24:15 | _bilgus_ | so far its not tagtree or backdrops |
| 12:25:03 | speachy | my daily driver has a vast 64MB to play with and a 128x64 monochrome screen. so... what memory pressure? :D |
| 12:28:29 | _bilgus_ | ok its in tree,c |
| 12:29:21 | _bilgus_ | might be my patch that reuses the previous loaded tree daat if it exists but i'll keep looking |
| 12:31:17 | _bilgus_ | tree_lock_cache() is spead far and wide but at least I have a place to start |
| 12:35:48 | _bilgus_ | hmm looks like it just couldn't make the alloc |
| 12:36:13 | _bilgus_ | it doesn't check if its valid |
| 12:36:15 | speachy | shrink the shufflebuf on 8MB targets? Or is this purely a tree problem? |
| 12:36:46 | _bilgus_ | the shuffle buf doesn't touch any of this anymore |
| 12:37:19 | _bilgus_ | maybe core_alloc should try shrinking the talk buf before it gives up |
| 12:39:24 | _bilgus_ | I see 3 potential ways 1. shrink the voice file, 2. make 8 mb targets give away the talk buffer like 2mb does, or 3 give core alloc a way to hail mary |
| 12:39:59 | _bilgus_ | 4. knock off 100k from the bin |
| 12:40:07 | speachy | (1) refers to the in-memory voice cache you mean? |
| 12:40:19 | _bilgus_ | yes |
| 12:40:46 | speachy | these are all flash-based devices right? |
| 12:41:13 | _bilgus_ | yeah the disk hit shouldnt be end of world |
| 12:41:37 | speachy | I think the smallest hdd-based is 16mb (ie the ihp-1xx/3xx) |
| 12:42:39 | speachy | that said I have a hard time seeing that this is resopnsible for that lag/crash on the erosqnative |
| 12:42:55 | _bilgus_ | so with two it both limits the size and gives it away freely |
| 12:43:19 | _bilgus_ | No i doubt it |
| 12:43:37 | _bilgus_ | figure this is being caught that looks like something unhandled |
| 12:47:38 | _bilgus_ | yeah so talk,c #if MEMORYSIZE <= 2 changes to #if MEMORYSIZE <= 8 |
| 12:48:25 | _bilgus_ | that limits it to 100k and gives it away at a whim |
| 13:00 |
| 13:10:10 | _bilgus_ | oh theres a second define to give it away freely so this is probably good enough |
| 13:10:44 | _bilgus_ | just limiting to 100k |
| 13:11:51 | _bilgus_ | since the playlist stuff is now aware of the size needed it should get it and limiting voice to 100k gives enough breathing room |
| 13:37:30 | *** | No seen item changed, no save performed. |
| 13:42:28 | | Quit Tonux (Ping timeout: 252 seconds) |
| 13:43:10 | | Join Tonux [0] (~Tonux@193.32.127.240) |
| 13:45:50 | | Join lebellium [0] (~lebellium@2a01cb0405d07f00d33a0da62bfc2206.ipv6.abo.wanadoo.fr) |
| 15:00 |
| 15:07:52 | | Join jacobk_ [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 15:07:57 | | Quit jacobk (Ping timeout: 276 seconds) |
| 15:25:06 | | Quit jacobk_ (Ping timeout: 248 seconds) |
| 15:25:33 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 15:37:32 | *** | Saving seen data "./dancer.seen" |
| 16:00 |
| 16:05:28 | | Join PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647) |
| 16:34:24 | | Quit jacobk (Ping timeout: 276 seconds) |
| 16:52:51 | | Join jacobk [0] (~quassel@2603:8080:b200:7b02::b71) |
| 16:53:46 | speachy | hmm, it would be useful if the "font coverage" page could generate lists of the actual codepoints that are missing for any given language+font combo. |
| 17:00 |
| 17:05:54 | _bilgus_ | downside to moving towards limiting MAX_CLIP_BUFFER_SIZE is it adds TALK_PROGRESSIVE_LOAD still looking at what that entails |
| 17:08:51 | | Quit jacobk (Ping timeout: 276 seconds) |
| 17:13:28 | speachy | turns out it has (disabled) code that will do just that. no good way to present/incorporate it though. |
| 17:20:11 | _bilgus_ | there are some thatd probably be very interested in the font coverage but the question is will anyone fix it if we do? |
| 17:24:51 | | Quit dconrad (Remote host closed the connection) |
| 17:25:04 | speachy | first step is visibility |
| 17:35:42 | speachy | https://translate.rockbox.org/whichfont.php |
| 17:36:03 | speachy | hover over a non-green box and you'll see the missing characters. crude but it does work. |
| 17:37:34 | *** | Saving seen data "./dancer.seen" |
| 17:41:28 | | Quit lebellium (Quit: Leaving) |
| 17:45:35 | rb-bluebot | Build Server message: New build round started. Revision 33495ef006, 345 builds, 9 clients. |
| 17:45:35 | rb-bluebot | fonts: Major update for 12-Fixed-SemiCond (1767 -> 4531 codepoints) by Solomon Peachy |
| 17:57:49 | rb-bluebot | Build Server message: Build round completed after 734 seconds. |
| 17:57:51 | rb-bluebot | Build Server message: Revision 33495ef006 result: All green |
| 18:00 |
| 18:31:20 | | Quit COMPL_EXE (Quit: WeeChat 4.2.2) |
| 18:50:34 | _bilgus_ | speachy thats pretty nice IMO |
| 18:54:46 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 19:00 |
| 19:03:21 | | Join jacobk [0] (~quassel@2603:8080:b200:7b02::b71) |
| 19:09:13 | _bilgus_ | ok it just enables the path for loading clips as you go doesn't appear to do anything untoward |
| 19:24:03 | | Quit jacobk (Ping timeout: 276 seconds) |
| 19:30:46 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 19:32:08 | OlsroFR | I noticed that a very small amount of my songs don't even load. I use Swinsian on Mac to manage my library, which maintains automatically a folder structure based on Album Artist/Album/File.extension. The issue here when a title is long (or an album artist because a lot of collabs), the whole path size seems to exceed the size of 250 |
| 19:32:58 | OlsroFR | I don't know if it would be possible to add an option to modify the size of MAX_PATH. iPods have a large amount of RAM and I would be ready to sacrifice some of it to avoid checking my whole library about cases like this one |
| 19:33:51 | OlsroFR | the issue here seems to be this is hard coded in a magic value statically allocated |
| 19:37:35 | *** | Saving seen data "./dancer.seen" |
| 19:37:58 | OlsroFR | 260* actually, not 250. Stored in MAX_PATH value. |
| 19:48:17 | _bilgus_ | We will not be modifying MAX_PATH |
| 19:48:24 | speachy | IF you bump it up by more than a little but, you'll run into stack overflows as well. |
| 19:48:27 | OlsroFR | I tried to connect my iPod to my old snow leopard mac with Stock OS. Open VLC through the contextual menu "Open it" fails, nothing happen under VLC. But if I drag and drop the song while VLC is opened, it works just fine and VLC starts to play it. So the file is here, properly copied and technically works. But it seems like it is not generally a |
| 19:48:27 | OlsroFR | good idea to exceeds 260 |
| 19:49:20 | speachy | Windows is limited to 260 characters too, IIRC. |
| 19:49:49 | _bilgus_ | you can do whatever for your own builds even compete with us with them if you prefer but its too many issues I will however accept patches that allow you to change it across codebase easily in a static way |
| 19:49:52 | OlsroFR | I sync my iPod on a Mac, which seems to not care about this 260 limits and copy everything just fine |
| 19:50:06 | speachy | you're free to modify your own builds however you wish |
| 19:52:03 | OlsroFR | I did not try to increase it (yet). But even if we do not change here, we may improve the error. I could figure out the issue because I had some portion of that code in my head, but the error for the user is not clear. From DB Browser the song will not play without error. From the file browser, it triggers a popup that is not explicit |
| 19:53:13 | speachy | MAX_PATH is a global #define already, but we do have places where paths are on the stack. |
| 19:54:43 | _bilgus_ | I can't say exactly where in the forum but this has been investigated already it might even be on the Won't Do List |
| 19:55:41 | speachy | I don't think we have any meaningful way to determine if a file operation fails because the file isn't found vs the path was too long |
| 19:56:28 | speachy | or at least nothing that's centralizeable |
| 19:59:58 | OlsroFR | I figured this out only with one song, I feel like the easy fix is just to rename it and go on. I now understand why iTunes standardizes completely the paths when copying songs; it makes things much more memory efficient and keep paths very short all the time by relying only on the db to store/retrieve relevant infos. |
| 20:00 |
| 20:02:38 | _bilgus_ | yep |
| 20:04:11 | _bilgus_ | one thing that could help is an actual CWD |
| 20:04:29 | OlsroFR | CWD ? |
| 20:04:53 | _bilgus_ | with current working directory you could know where you were starting from and effectively allow longer paths |
| 20:05:48 | OlsroFR | it will probably only work from file browser then, DB browser will still be screwed by this kind of workaround unfortunately |
| 20:05:57 | _bilgus_ | yep |
| 20:06:36 | _bilgus_ | but the db browser can do something similar |
| 20:06:55 | OlsroFR | that specific song was so abusing metadata. All collabs were wrote on the title + on the album + on the album artist field lol |
| 20:07:06 | _bilgus_ | because of the scan paths |
| 20:09:17 | speachy | hah, id3v2 maxes out at 16MB. |
| 20:14:10 | _bilgus_ | I was thinking about dirplay today I suppose the main issue is the user wants the track to play faster and the playlist code takes playback ram to do it faster what if we allowed them to do lazier loading to get a track playing and some amount of skipping |
| 20:14:48 | _bilgus_ | I suppose the next bitch would be then that skipping tracks causes delays |
| 20:15:08 | speachy | this isn't a problem for "reasonable" playlist lengths. |
| 20:15:32 | speachy | but when folks want to have tens of thousands of tracks on shuffle or whatever... |
| 20:15:38 | _bilgus_ | Ah, good point esp with OLSROFRs patch |
| 20:16:47 | OlsroFR | It's not really worrying but I notice a huge delay on my ipod 4Th gen when I switch especially several tracks in a row, yes. It happens often |
| 20:16:49 | speachy | btw, cwd will still not work in the general case; we need absolute paths for most stuff to work. |
| 20:17:25 | _bilgus_ | the codecs |
| 20:17:40 | OlsroFR | All my tracks are in musepack (mpc) SV8 |
| 20:17:51 | _bilgus_ | we can show you it but you can't play it lol |
| 20:18:24 | _bilgus_ | might allow you to edit it on device though |
| 20:19:00 | OlsroFR | I don't know, but showing infos about the file also crash (pretty logical since it rely on a full path to do the operation) |
| 20:21:40 | | Quit bpye (Quit: Ping timeout (120 seconds)) |
| 20:22:04 | OlsroFR | I leave for today, thanks for the answers |
| 20:22:06 | | Quit OlsroFR (Quit: Client closed) |
| 20:22:21 | | Join bpye [0] (~bpye@user/bpye) |
| 20:22:37 | _bilgus_ | I've been browsing this file browser for like an hour it seems to not be any slower |
| 20:23:01 | _bilgus_ | maybe it has something to do with files in a directory I think my max is like 10000 |
| 20:24:38 | _bilgus_ | its pretty slow if I wrap the scroll around on first load |
| 20:34:17 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 20:48:05 | speachy | ... maybe we're hitting intrinsic limits of what we can accomplish on 20-year-old microcontrollers with limited resources. :D |
| 21:00 |
| 21:05:29 | speachy | wow, didn't realize the ARM7TDMI core was introduced in *1994* |
| 21:37:36 | *** | Saving seen data "./dancer.seen" |
| 21:42:59 | | Join PSparky|Ryzen7 [0] (~S|h|a|w|n@user/shawn/x-4432647) |
| 21:43:10 | | Quit PheralSparky (Ping timeout: 252 seconds) |
| 22:00 |
| 22:10:18 | | Quit jackie (Ping timeout: 246 seconds) |
| 22:12:26 | | Join jackie [0] (~jackie@banana-new.kilobyte22.de) |
| 22:30:19 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 22:31:59 | | Quit dconrad (Client Quit) |
| 22:56:29 | aaabbb | if it's just the ui being slow then it's an optimization problem not a performance problem. the ARM7TDMI is pretty powerful |
| 23:00 |
| 23:08:47 | | Quit massiveH (Quit: Leaving) |
| 23:37:37 | *** | Saving seen data "./dancer.seen" |
icon identifies that the person is a core developer (has commit access).