| 00:17:26 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 00:21:30 | | Quit dconrad (Ping timeout: 246 seconds) |
| 00:29:09 | | Quit othello7 (Ping timeout: 248 seconds) |
| 01:00 |
| 01:09:19 | | Quit massiveH (Ping timeout: 260 seconds) |
| 01:23:35 | | Join massiveH [0] (~massiveH@2600:4040:a982:dc00:74ad:34cc:9239:869b) |
| 01:28:58 | *** | Saving seen data "./dancer.seen" |
| 01:32:00 | | Join massive_H [0] (~massiveH@2600:4040:a982:dc00:74ad:34cc:9239:869b) |
| 01:35:33 | | Quit massiveH (Ping timeout: 276 seconds) |
| 01:52:40 | | Quit massive_H (Quit: Leaving) |
| 02:00 |
| 02:01:39 | _bilgus | OlsroFR I think this looks pretty good I even added some checking to get an idea of the distribution 1000 runs hits every entry in 10000 with a 100 track playlist https://onlinegdb.com/gyCzmW3eG |
| 02:35:44 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 02:40:26 | | Quit dconrad (Ping timeout: 272 seconds) |
| 02:40:50 | _bilgus | and here is one for checking the distribution between them https://www.onlinegdb.com/OGt-gjUQU5 |
| 02:41:11 | _bilgus | so in 600 runs yours gets all entries in 600 mine misses 21 |
| 02:41:48 | _bilgus | but at 1000 runs it gets them all and looking at the distribution they are pretty similar |
| 02:43:03 | _bilgus | what if we use the playlist buffer to make your bool array if it is capable and if not we fall back to this thts should be best of both worlds |
| 02:44:07 | _bilgus | I could also arge this is probably good enough.. |
| 02:44:14 | _bilgus | argue* |
| 03:00 |
| 03:28:59 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:07:07 | | Join lebellium [0] (~lebellium@2a01cb0405d07f00d33a0da62bfc2206.ipv6.abo.wanadoo.fr) |
| 04:46:48 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 05:00 |
| 05:04:18 | | Quit jacobk (Ping timeout: 248 seconds) |
| 05:05:10 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 05:29:00 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:45:07 | | Quit Moriar (Quit: Leaving.) |
| 07:00 |
| 07:29:02 | *** | Saving seen data "./dancer.seen" |
| 07:59:54 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 08:00 |
| 08:38:27 | OlsroFR | _bilgus Did some tests with playlistsize=2000 maxtracks=30161 your code requires 171 iterations to distribute at least one of all, my code 106. But well I agree is not that bad and it seems like at least now it can pick the last songs as possible candidates |
| 08:38:38 | OlsroFR | https://gerrit.rockbox.org/r/c/rockbox/+/5917 just pushed a new revision to use the plugin buffer, it seems to work perfectly :) |
| 08:39:17 | OlsroFR | I added checks if it fails, but the space that need to be allocated seems to be so low that it will should never fail |
| 08:41:05 | OlsroFR | if you feel like it can fail, feel free to integrate your code in top of my patch and to make it execute if it fails |
| 08:42:58 | OlsroFR | I was kinda afraid at first to use the plugin buffer because my first revisions needed 256kb of static allocation and I was afraid of the playlist_viewer.c but it should not be a problem. Now I know that Playlist_viewer.c (which requires also the plugin buffer) is completely unrelated to tagtree browser and should never conflict with it. So it |
| 08:42:58 | OlsroFR | should be all fine. |
| 08:48:40 | OlsroFR | I also modified my code to always use a 1024 segments size now matter if it is a low ram player or no. It is so low with plugin buffer that it should also never fail, so there's no reason anymore to restrict to 128 bits |
| 08:49:27 | | Join macaronus_ [0] (~macaronus@user/MaCaRoNus) |
| 08:51:48 | | Quit ThreeeePac (Ping timeout: 246 seconds) |
| 08:52:14 | | Quit OlsroFR (Quit: Client closed) |
| 09:00 |
| 09:11:12 | | Join baltazar [0] (~baltazar@user/baltazar) |
| 09:11:27 | | Quit baltazar (Client Quit) |
| 09:12:27 | | Join baltazar [0] (~baltazar@user/baltazar) |
| 09:12:28 | | Quit baltazar (Client Quit) |
| 09:13:00 | | Join baltazar [0] (~baltazar@user/baltazar) |
| 09:13:47 | _bilgus | I'm thinking more like if you can get playlist_max slots in plugin buf we do that otherwise do the rand thing then there can be very minimal code to do the fisher-yates and use random permutation if not |
| 09:21:09 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 09:21:16 | OlsroFR | I don't understand |
| 09:22:25 | OlsroFR | now my last patch reduced the 1K in binary size which was the main issue, so the memory impact is now minimal. Do you mean that it is possible to do the same thing with even less codelines ? |
| 09:29:06 | *** | Saving seen data "./dancer.seen" |
| 09:39:30 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 10:00 |
| 10:30:54 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 10:37:09 | | Quit othello7 (Ping timeout: 248 seconds) |
| 10:41:47 | _bilgus | i'm saying we can use the randarr = getpluginbuffer(bufsz) as the shuffle array if it has playlist_max slots (check that sizeof(bool) * playlist_max < bufsz) now shuffle the whole randarr and store the pointer then when we go thru the loop if randarr != null and randarr[i] == false {comntinue} |
| 10:42:27 | _bilgus | if randarr doesn't exist i falls back to random permutation |
| 10:43:01 | _bilgus | then we get rid of the corner cases since its no longer chunked and the logic gets simple |
| 10:47:06 | | Quit macaronus_ (Remote host closed the connection) |
| 10:47:26 | | Join macaronus_ [0] (~macaronus@user/MaCaRoNus) |
| 10:49:44 | OlsroFR | ohhhh I see ! Now I understand your point. Let's code that |
| 10:58:19 | | Quit macaronus_ (Ping timeout: 264 seconds) |
| 11:00 |
| 11:01:26 | | Join macaronus [0] (~macaronus@user/MaCaRoNus) |
| 11:11:52 | _bilgus | g#5918 I haven't tested it yet and I still want to clean it up a bit |
| 11:11:55 | rb-bluebot | Gerrit review #5918 at https://gerrit.rockbox.org/r/c/rockbox/+/5918 : Tagtree selective random playlist −− rewrite by William Wilgus |
| 11:13:03 | dconrad | speachy: x1000boot.make is preventing us from compiling the v3 bootloader, it looks like it's independently determining $(MODELNAME).h instead of getting it from config.h, I assume for code size reasons? (ln. 15) |
| 11:13:36 | dconrad | I'm afraid I don't know enough about makefiles to know if there's an easy way around this without gotchas |
| 11:14:35 | _bilgus | I don't think it matters if you know about makefiles there are always gotchas lol |
| 11:14:57 | dconrad | well maybe we can figure out a magic incantation tho :P |
| 11:15:56 | speachy | the naive thing to do would be replce $(FIRMDIR)/export/config/$(MODELNAME).h with $(FIRMDIR)/export/config.h and see what happens |
| 11:16:27 | dconrad | yeah I suppose so... I guess the thing to look at would be whether the bootloader balloons in size? |
| 11:16:53 | speachy | these files are used as a preprocessor input into the bootloader link script |
| 11:17:32 | speachy | (or asm files) |
| 11:18:11 | speachy | config.h _should_ always be safe to include in those contexts too |
| 11:18:54 | | Quit macaronus (Ping timeout: 260 seconds) |
| 11:19:03 | dconrad | yeah it looks like it's the same as the v1 bootloader I built without that change, 92k |
| 11:19:29 | dconrad | gotcha |
| 11:23:01 | dconrad | well, it seems to work that way... I should check that it doesn't break m3k somehow too |
| 11:23:23 | speachy | m3k and q1 |
| 11:23:54 | dconrad | unfortunately I don't have a q1, but I've got an m3k here |
| 11:26:03 | dconrad | well it usbboots ok |
| 11:29:10 | *** | Saving seen data "./dancer.seen" |
| 11:31:38 | OlsroFR | _bilgus https://gerrit.rockbox.org/r/c/rockbox/+/5918/6..7 here is what could look the "final code". Seems to work just fine |
| 11:32:42 | OlsroFR | It's basically your current code + I added the logic to try to allocate in the plugin buffer if possible. If it is possible, I use the full array logic. If not, it switches to your code |
| 11:33:19 | _bilgus | look at 5918 it does all this |
| 11:33:21 | OlsroFR | Of course you just said me that you need to do more tests with your permutation logic so feel free to modify this merge request accordingly if necessary |
| 11:35:13 | OlsroFR | Ah ok. So I let you finish your code. Send me the merge request when I can look at it, thank you |
| 11:35:47 | _bilgus | its good to go now I just added some comments and moved a few things around |
| 11:36:43 | _bilgus | being that each half already worked it should now too unless I added a bug, I'm going to start gennerating some playlists on the device and make sure |
| 11:38:39 | _bilgus | I've got something off apparently as it was way too fast |
| 11:42:23 | OlsroFR | Just reviewed your current merge request. I can't judge your random logic but all the rest seems perfect, and it should use the boolean array if possible |
| 11:44:31 | _bilgus | the random should be fine that already worked I'm just checking that the bool_array part is working proper |
| 11:46:04 | OlsroFR | OK |
| 11:46:18 | OlsroFR | if it is working in your tests, you can merge it |
| 11:47:04 | OlsroFR | I am very satisfied by this compromise, which also leads to a randomness that is even with higher quality than the randomness with 1024 sized segments |
| 11:47:20 | OlsroFR | and by using the plugin buffer, it should basically work all the time |
| 11:47:55 | _bilgus | wow it is working, it appears to be about half way through its WAY faster |
| 11:48:43 | OlsroFR | it's as fast as it can possible be :) |
| 11:48:46 | OlsroFR | possibly |
| 11:49:28 | _bilgus | I figured it had failed as fast as it is |
| 11:50:48 | _bilgus | yes I'm happy with this as well its still a bit smaller and you have minimal corner cases amd its pretty easy to follow |
| 11:51:27 | OlsroFR | I fully agree, this new compromise satisfy me fully |
| 11:51:35 | _bilgus | perfect |
| 11:52:15 | OlsroFR | and well, it's as simple as it can be, clearly. I will tell you another sentence about perfectness: "less is more". Here, clearly, less is more ;) |
| 11:53:25 | OlsroFR | The only edge-case that future devs will have to take care is to never use the plugin_buffer in any related context or it will create strange issues |
| 11:54:46 | _bilgus | you'd already be in the tagcache so to do that you'd have to either start a plugin or do something out of band like in an interrupt and I don't see that happening |
| 11:55:16 | OlsroFR | Ok |
| 11:55:28 | OlsroFR | so it is all fine |
| 11:55:32 | _bilgus | the other thing is if they do it'll still be randomized data and we check that we haven't added too many tracks |
| 11:55:41 | _bilgus | so it'd just work |
| 11:56:26 | OlsroFR | I abandoned my own merge request since it is obsolete now |
| 11:56:50 | OlsroFR | don't forget also to merge this one if it is good to you: https://gerrit.rockbox.org/r/c/rockbox/+/5919 |
| 11:57:26 | _bilgus | we've already seeded the array so it won't corrupt their data and if they corrupt us in the yield it won't crash the distribution will just be off |
| 11:57:52 | _bilgus | you'll have to give me a bit on that one |
| 11:58:11 | _bilgus | i'll sit down and look at it this eve time dependent |
| 11:58:32 | OlsroFR | Okay :) |
| 12:00 |
| 12:14:09 | rb-bluebot | Build Server message: New build round started. Revision a86e2b5c6e, 337 builds, 10 clients. |
| 12:14:10 | rb-bluebot | Tagtree selective random playlist −− rewrite by William Wilgus |
| 12:25:00 | rb-bluebot | Build Server message: Build round completed after 651 seconds. |
| 12:25:02 | rb-bluebot | Build Server message: Revision a86e2b5c6e result: All green |
| 12:26:56 | _bilgus | ahh that looks much better on the codesize board too |
| 12:29:05 | rb-bluebot | Build Server message: New build round started. Revision a5462d6192, 337 builds, 10 clients. |
| 12:29:06 | rb-bluebot | erosqnative: Give erosqnative_v3 its own target ID and modelname by Dana Conrad |
| 12:29:53 | speachy | oh nice. we haven't seen green like that in a hot minute |
| 12:30:44 | _bilgus | well we know for the future we need targetID and modelname now lets hope we get a new port before we all forget |
| 12:31:51 | dconrad | ah, an excuse to buy another hibyos player... lol |
| 12:33:27 | speachy | this was a corner case though |
| 12:34:52 | _bilgus | OH, ok just because they share most of the backend? |
| 12:35:17 | spork | maybe try something else dconrad, perhaps a shanling m1 plus (so i have an excuse to get one too) |
| 12:35:27 | _bilgus | lol |
| 12:35:31 | speachy | yeah, I wanted to make them share the same ID but it would have been messier overall |
| 12:36:04 | speachy | TARGT_ID is ued by the plugin and codec magic header bits. |
| 12:36:29 | _bilgus | I hope someone comes out with something clip size with capable hardware someday |
| 12:36:54 | speachy | I'd be inclined to agree, except my eyes suck too much for that now. :( |
| 12:37:04 | _bilgus | those big players get really banged up in my pockets |
| 12:38:14 | _bilgus | yeah I notice the font sizes on all my other devices creeping ever higher but thats a tiny screen so voicing helps |
| 12:38:19 | dconrad | looks pretty fancy spork... |
| 12:38:53 | spork | x2000 but should be fairly similar to other 'mtouch' olayers |
| 12:38:55 | spork | players |
| 12:39:00 | spork | and similar to hibyos |
| 12:39:02 | speachy | tbh I'm still loving my X3. the funky buttons and voice prompts make it _really_ nice to use without looking |
| 12:39:36 | _bilgus | thats a nice player I like the metal case thast the only reason its still alive likely |
| 12:39:48 | _bilgus | mine that is |
| 12:39:48 | rb-bluebot | Build Server message: Build round completed after 645 seconds. |
| 12:39:50 | rb-bluebot | Build Server message: Revision a5462d6192 result: 4 errors 0 warnings |
| 12:39:57 | rb-bluebot | Build Server message: New build round started. Revision 89fd4d0a51, 337 builds, 10 clients. |
| 12:39:57 | rb-bluebot | hibyOS: OF patcher script for Native ports by Dana Conrad |
| 12:41:23 | dconrad | hmm, tools/configure must not get re-run on buildfarm stuff...? |
| 12:41:55 | dconrad | well, we only need that on bootloader as well I believe |
| 12:43:11 | speachy | configure is never re-run; all buildfarm stuff is pristine |
| 12:44:55 | speachy | goes boom in the lua plugin |
| 12:45:51 | _bilgus | ketmaps? |
| 12:45:55 | _bilgus | key* |
| 12:45:58 | speachy | must not be including EXTRA_DEFINES somewhere |
| 12:49:30 | speachy | and if that's included, it goes boom. |
| 12:49:58 | speachy | the simple "solution" is to remove that intentional #error |
| 12:50:17 | speachy | but IMO this should be fixed properly. |
| 12:50:26 | rb-bluebot | Build Server message: Build round completed after 629 seconds. |
| 12:50:27 | rb-bluebot | Build Server message: Revision 89fd4d0a51 result: 4 errors 0 warnings |
| 12:50:34 | rb-bluebot | Build Server message: New build round started. Revision 83890c249c, 337 builds, 10 clients. |
| 12:50:35 | rb-bluebot | FS #13482 - Corrected italian translation (Alessio Lenzi) by Solomon Peachy |
| 12:50:50 | dconrad | it does build for me here if we only check for that if BOOTLOADER is defined |
| 12:51:45 | dconrad | is that an acceptable solution? |
| 12:53:33 | dconrad | g#5920 is available if so |
| 12:53:37 | rb-bluebot | Gerrit review #5920 at https://gerrit.rockbox.org/r/c/rockbox/+/5920 : erosqnative: only check for EROSQN_VER if bootloader build by Dana Conrad |
| 12:53:45 | dconrad | if not, disregard |
| 12:55:40 | speachy | the underlynig problem appears to be that it does the button_helper script, which is then passed to a host compiler. that's what goes boom. |
| 12:56:14 | _bilgus | button_helper.pl gets fed by rbdefines_helper.pl and it does a compile with symbols emitted |
| 12:56:38 | speachy | ok I think I have it going now. |
| 12:57:14 | | Quit OlsroFR (Quit: Client closed) |
| 12:57:20 | _bilgus | since it parses config its probably picking that up and has no concept of the #ifndef logic |
| 12:57:44 | speachy | the hostcc side just needed $(EXTRA_DEFINES) |
| 12:57:58 | _bilgus | ah |
| 12:58:07 | speachy | because it manually includes button.h on the cmdline, that pulls in config.h |
| 12:58:34 | speachy | this could bite us later but I guess that's what the build farm is for. :D |
| 12:58:56 | speachy | pushed, will get picked up after this build. |
| 12:59:11 | speachy | (oh the joys of queued stuff perpetuating the red..) |
| 12:59:53 | _bilgus | I opened rbdefines_helper.pl and didn't realize I wrote it till I looked at the header lol |
| 13:00 |
| 13:00:13 | speachy | "what idiot wote this dreck?" "....oh." |
| 13:00:47 | _bilgus | No actually I was like this looks like it took a long time |
| 13:00:53 | rb-bluebot | Build Server message: Build round completed after 620 seconds. |
| 13:00:54 | rb-bluebot | Build Server message: Revision 83890c249c result: 4 errors 0 warnings |
| 13:01:01 | rb-bluebot | Build Server message: New build round started. Revision 37ca92d276, 337 builds, 10 clients. |
| 13:01:01 | rb-bluebot | lua: button_helper needs $(EXTRA_DEFINES) on the host build side by Solomon Peachy |
| 13:02:26 | dconrad | it's amazing in all the testing I did this morning it never actually occurred to me to do a sanity build of the actual firmware 🤦, go figure |
| 13:02:45 | dconrad | oh well |
| 13:02:49 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 13:02:52 | speachy | .... yeah, gotta love that. |
| 13:04:07 | dconrad | I'll grab this new build and put it on my player as well just to double check |
| 13:04:26 | _bilgus | the build farm saves my bacon enough thatyou need not worry about your one time. for a few of the bigger things I'd do a full buildfarm build on my machine before I pushed stuff |
| 13:04:47 | dconrad | I bet that took /ages/ |
| 13:04:55 | _bilgus | like a day |
| 13:05:18 | _bilgus | maybe two been long enough ago that my pc was a lot slower than now |
| 13:05:49 | _bilgus | selective actions was the really trying one |
| 13:07:36 | _bilgus | I think I had like 50 revisions and abandoned it 1 or two times before I was finally happy ith it |
| 13:08:18 | dconrad | well it works really well, so good job 👍 |
| 13:08:34 | speachy | if you want I can ship you a 4 node supermicro fattwin server. :D |
| 13:09:27 | speachy | then again, that probably will cost more than the system is worth. |
| 13:09:37 | speachy | (though it might offset your heating costs in the winter) |
| 13:11:01 | rb-bluebot | Build Server message: Build round completed after 601 seconds. |
| 13:11:03 | rb-bluebot | Build Server message: Revision 37ca92d276 result: 4 errors 0 warnings |
| 13:11:41 | _bilgus | lol I had my hands on a big ole server at one point till I realized the total clock count was just barely faster than a 4ghz AMD and itd be really hard to find graphics cards |
| 13:11:47 | speachy | uh... I built this thing myself? |
| 13:12:23 | _bilgus | I'll be back in a bit if you need I can look into rbdefines_helper.pl |
| 13:13:48 | speachy | I built it twice back-to-back, once failed, one succeeded |
| 13:15:00 | speachy | now I can't get it to fail. |
| 13:16:41 | speachy | maybe a ccache thing? |
| 13:29:13 | *** | Saving seen data "./dancer.seen" |
| 13:57:06 | | Quit dconrad (Remote host closed the connection) |
| 14:00 |
| 14:17:47 | | Join dconrad [0] (~dconrad@2604:2800:6:6929:894c:6fb3:998d:3be7) |
| 14:19:51 | | Quit dconrad (Remote host closed the connection) |
| 14:19:59 | | Join dconrad [0] (~dconrad@2604:2800:6:6929:894c:6fb3:998d:3be7) |
| 14:32:11 | rb-bluebot | Build Server message: New build round started. Revision 1f1b3bce86, 337 builds, 10 clients. |
| 14:32:11 | rb-bluebot | FS #13480: Updated Russian Translation (Dimitry Prozorov) by Solomon Peachy |
| 14:44:33 | rb-bluebot | Build Server message: Build round completed after 744 seconds. |
| 14:44:36 | rb-bluebot | Build Server message: Revision 1f1b3bce86 result: 4 errors 0 warnings |
| 14:48:33 | | Quit speachy (Quit: WeeChat 4.3.5) |
| 14:51:00 | dconrad | can we request that build be done on a different machine somehow? |
| 14:54:07 | dconrad | oh, nevermind it's a different machine each time |
| 15:00 |
| 15:13:57 | _bilgus | OlsroFR I have some comments on your patch I'd try to stop carrying around any info you can get later in that struct that holds the entry info you should be able to co-opt attr and put your flags there and hopefully remove the viewbuf pointer in favor of a fixed scheme (if it needs to be variable you could use flags to record the size and just waste a bit with each entry) like have a flag that signals its a 32 byte buffer another |
| 15:13:57 | _bilgus | for 64 bytes and a so forth |
| 15:15:01 | _bilgus | attr only has 2 flags so that leaves you about 29 more to play with |
| 15:16:31 | _bilgus | strmemccpy is a safe strcpy that return char* just after the last NULL in the string |
| 15:17:15 | _bilgus | (little more convenient too) |
| 15:19:58 | _bilgus | another option might be to split attr into two int16_ts and you could still have some flasg and store the buffer size |
| 15:29:14 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:03:00 | | Quit pixelma (Quit: .) |
| 17:03:01 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 17:04:01 | | Join pixelma [0] (marianne@p4fd7f6f5.dip0.t-ipconnect.de) |
| 17:04:01 | | Join amiconn [0] (jens@p4fd7f6f5.dip0.t-ipconnect.de) |
| 17:06:47 | | Join Everything [0] (~Everythin@109.162.122.37) |
| 17:07:34 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 17:08:12 | OlsroFR | _bilgus https://gerrit.rockbox.org/r/c/rockbox/+/5919 new patch pushed, should be perfect now (or closer to it) |
| 17:10:06 | rb-bluebot | Build Server message: New build round started. Revision a7cfee640d, 337 builds, 10 clients. |
| 17:10:07 | rb-bluebot | erosqnative: only check for EROSQN_VER if bootloader build by Dana Conrad |
| 17:14:13 | | Quit OlsroFR (Quit: Client closed) |
| 17:22:36 | rb-bluebot | Build Server message: Build round completed after 752 seconds. |
| 17:22:38 | rb-bluebot | Build Server message: Revision a7cfee640d result: All green |
| 17:22:50 | dconrad | woohoo! |
| 17:23:32 | _bilgus | OlsroFR that looks much better two small things left ditch the (slower & no search) from the strings |
| 17:23:50 | _bilgus | and = NULL instead of = 0 for pointers |
| 17:23:56 | | Quit lebellium (Quit: Leaving) |
| 17:24:07 | _bilgus | I don't have time to test i'll try to do it later |
| 17:24:23 | _bilgus | tonight or tomorrow eve |
| 17:27:38 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 17:29:15 | *** | Saving seen data "./dancer.seen" |
| 17:29:26 | dconrad | yep, that build seems to work as expected 👍 |
| 17:30:50 | dconrad | I can build the bootloaders later to put on the download site |
| 17:31:50 | OlsroFR | _bilgus Thanks. All done, just pushed a new patch |
| 17:32:52 | | Quit dconrad (Remote host closed the connection) |
| 17:58:52 | | Quit OlsroFR (Quit: Client closed) |
| 18:00 |
| 18:02:59 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 18:08:53 | | Quit dconrad (Ping timeout: 248 seconds) |
| 18:37:03 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 18:41:39 | | Quit dconrad (Ping timeout: 260 seconds) |
| 19:00 |
| 19:29:19 | *** | Saving seen data "./dancer.seen" |
| 19:37:20 | | Join massiveH [0] (~massiveH@2600:4040:a982:dc00:74ad:34cc:9239:869b) |
| 19:41:44 | | Quit jacobk (Ping timeout: 260 seconds) |
| 19:50:09 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 20:00 |
| 20:37:05 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 20:59:39 | | Quit Everything (Quit: leaving) |
| 21:00 |
| 21:16:22 | | Quit baltazar (Ping timeout: 272 seconds) |
| 21:17:28 | | Join baltazar [0] (~baltazar@user/baltazar) |
| 21:23:10 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 21:27:29 | | Quit dconrad (Ping timeout: 245 seconds) |
| 21:29:21 | *** | Saving seen data "./dancer.seen" |
| 21:41:04 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 21:57:33 | _bilgus | OlsroFR I just tried the patch it works pretty well good job, I'll wait till we are both around to push it in case something comes up bc atm I don't feel like fixing it if something blows up |
| 22:00 |
| 22:16:52 | _bilgus | So I still notice a issue with the Database unrelated to all this and that is if you go through the DB and do something that takes awhile pick a track goto the WPS then return to the DB you have to wait for all that to be loaded again I'm thinking perhaps we save the state on the way out rather than re-calculating and since you'll be starting a song anyway you can get some ram from the buffer lib and if the fevice wants to move or |
| 22:16:52 | _bilgus | shrink it no problem or we could delete it |
| 22:21:55 | _bilgus | For instance, search for a track play the track then exit the wps |
| 22:43:43 | dconrad | speachy: here's a zip file with both bootloaders if we're ready to put them on the downloads site |
| 22:43:51 | dconrad | https://drive.google.com/file/d/1EtAcyENekbchajueseuwKdoAhJz7KJg0/view?usp=sharing |
| 23:00 |
| 23:13:06 | | Quit massiveH (Quit: Leaving) |
| 23:17:42 | | Quit Moriar (Ping timeout: 246 seconds) |
| 23:29:23 | *** | Saving seen data "./dancer.seen" |
| 23:37:17 | | Join aaabbb [0] (sitku@user/aaabbb) |
| 23:53:58 | | Quit dconrad (Remote host closed the connection) |
icon identifies that the person is a core developer (has commit access).