| 00:37:36 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 00:42:48 | | Quit dconrad (Ping timeout: 276 seconds) |
| 01:00 |
| 01:06:54 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 01:23:53 | *** | Saving seen data "./dancer.seen" |
| 02:00 |
| 02:18:46 | | Quit dconrad (Remote host closed the connection) |
| 02:31:37 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 02:36:28 | | Quit dconrad (Ping timeout: 265 seconds) |
| 02:51:27 | | Quit Jinx (Ping timeout: 265 seconds) |
| 03:00 |
| 03:23:55 | *** | Saving seen data "./dancer.seen" |
| 03:36:09 | | Join halloy6399 [0] (~halloy639@aaubervilliers-198-1-21-253.w92-159.abo.wanadoo.fr) |
| 03:36:31 | | Nick halloy6399 is now known as OlsroFR (~halloy639@aaubervilliers-198-1-21-253.w92-159.abo.wanadoo.fr) |
| 03:37:00 | OlsroFR | I still cannot upload my theme, getting same error on the site: " Disable main menu scrolling is not a allowed theme setting." |
| 03:37:45 | | Quit Skyrider (Quit: ZNC - 1.6.0 - http://znc.in) |
| 03:43:52 | | Join Skyrider [0] (~Skyrider@static.219.32.201.138.clients.your-server.de) |
| 03:47:24 | | Quit OlsroFR (Remote host closed the connection) |
| 04:00 |
| 04:45:04 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 04:49:25 | | Quit dconrad (Ping timeout: 248 seconds) |
| 05:00 |
| 05:04:49 | | Quit jacobk (Ping timeout: 260 seconds) |
| 05:05:21 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 05:23:56 | *** | Saving seen data "./dancer.seen" |
| 05:30:07 | | Join reb [0] (~reb@80.208.34.77) |
| 05:42:25 | reb | hey, i don't normally do any sort of collaborative work like this with others, so my apologies for being a bit behind (a noob). to show graditude for rockbox re-igniting my love of DAPs and overall quality of life improvements of my device, i decided to, at the very least, contribute in translation efforts. i saw the lithuanian language has been |
| 05:42:26 | reb | forgotten since 2009, haha. so, as a native from LT, i've translated some chunks. but i am not entirely sure what's some appropriate places to submit the work i've done (excluding sending it as a bugfix...i am ESL so i was confused by the language barrier if that'd be the way to go. aka i cannot decide if "create patch" or "create full" is the way |
| 05:42:26 | reb | to go). let me know if i should do this anywhere elsewhere! also, i plan to try and translate 90% (or more) for LT in the future, especially if no other native speakers are available to help out in this area :) so far i just added a lot of missing words, and corrected a couple of outdated LT terminology/incorrect use of words in the context of |
| 05:42:27 | DBUG | Enqueued KICK reb |
| 05:42:27 | reb | grammar. |
| 05:44:05 | reb | again, my apologies for struggling to comprehend english directions, but i am trying my best as an ESL speaker ^^; |
| 06:00 |
| 06:49:12 | | Quit chamlis (Remote host closed the connection) |
| 06:49:26 | | Join chamlis [0] (~chamlis@user/chamlis) |
| 06:58:31 | | Quit chamlis (Remote host closed the connection) |
| 06:58:46 | | Join chamlis [0] (~chamlis@user/chamlis) |
| 07:00 |
| 07:02:12 | | Quit chamlis (Remote host closed the connection) |
| 07:02:27 | | Join chamlis [0] (~chamlis@user/chamlis) |
| 07:03:29 | | Quit chamlis (Remote host closed the connection) |
| 07:03:44 | | Join chamlis [0] (~chamlis@user/chamlis) |
| 07:20:27 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 07:23:59 | *** | Saving seen data "./dancer.seen" |
| 07:24:15 | | Quit Moriar (Ping timeout: 246 seconds) |
| 07:24:49 | | Quit dconrad (Ping timeout: 252 seconds) |
| 07:29:30 | | Quit olspookishmagus (Ping timeout: 246 seconds) |
| 07:31:11 | | Quit chamlis (Remote host closed the connection) |
| 07:31:25 | | Join chamlis [0] (~chamlis@user/chamlis) |
| 07:32:22 | | Quit chamlis (Remote host closed the connection) |
| 07:32:36 | | Join chamlis [0] (~chamlis@user/chamlis) |
| 07:37:35 | | Join halloy6399 [0] (~halloy639@aaubervilliers-198-1-21-253.w92-159.abo.wanadoo.fr) |
| 07:37:49 | | Nick halloy6399 is now known as OlsroFR (~halloy639@aaubervilliers-198-1-21-253.w92-159.abo.wanadoo.fr) |
| 07:38:18 | | Quit chamlis (Remote host closed the connection) |
| 07:38:31 | | Join chamlis [0] (~chamlis@user/chamlis) |
| 07:41:22 | OlsroFR | _bilgus: https://gerrit.rockbox.org/r/c/rockbox/+/5903 https://gerrit.rockbox.org/r/c/rockbox/+/5901 I have processed all your review comments. |
| 07:43:30 | | Quit chamlis (Remote host closed the connection) |
| 07:43:45 | | Join chamlis [0] (~chamlis@user/chamlis) |
| 07:44:57 | | Quit chamlis (Remote host closed the connection) |
| 07:45:11 | | Join chamlis [0] (~chamlis@user/chamlis) |
| 07:49:34 | OlsroFR | and also added manual entries to explain that shuffling in the context of the database browser is going to pick random from the whole view if it exceeds the limit of the system |
| 07:51:11 | edhelas_ | OlsroFR thanks for your awesome contributions ! |
| 08:00 |
| 08:00:07 | rb-bluebot | Build Server message: New build round started. Revision 054ba76d81, 337 builds, 9 clients. |
| 08:00:07 | rb-bluebot | Morse code cheat sheet, better use [of] pixels available on screen by William Wilgus |
| 08:01:36 | _bilgus | OlsroFR, morse keybpard is pushed I merged it with 5904 which can now be abandoned |
| 08:01:39 | | Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 08:03:43 | OlsroFR | thank you ! 5904 is now abandoned |
| 08:04:28 | _bilgus | you are still tring to do a string compare for that string in tagnav |
| 08:04:58 | _bilgus | i'm not doing a string compare in my directoy loop for a single word in a single file |
| 08:05:19 | _bilgus | well two words in a single file |
| 08:06:12 | _bilgus | see 2167 for an example of how to parse the tagnav file |
| 08:06:36 | | Quit olspookishmagus (Ping timeout: 246 seconds) |
| 08:07:58 | OlsroFR | OK, will look into it |
| 08:08:07 | _bilgus | thanks. |
| 08:12:46 | _bilgus | in tagtree.c (also in 2167) you see here: https://github.com/Rockbox/rockbox/blob/master/apps/tagtree.c#L1465 thats where you will check your tag but it won't be a strcmp but a enum match to https://github.com/Rockbox/rockbox/blob/master/apps/tagtree.c#L362 |
| 08:12:48 | rb-bluebot | Build Server message: Build round completed after 761 seconds. |
| 08:12:50 | rb-bluebot | Build Server message: Revision 054ba76d81 result: All green |
| 08:12:59 | rb-bluebot | Build Server message: New build round started. Revision edd607c392, 337 builds, 9 clients. |
| 08:12:59 | rb-bluebot | FS #13473: Update Korean translation (Hoseok Seo) by Solomon Peachy |
| 08:15:04 | | Nick jn_ is now known as jn (~quassel@user/jn/x-3390946) |
| 08:17:44 | | Join olspookishmagus [0] (~pookie@83.212.124.75) |
| 08:25:18 | rb-bluebot | Build Server message: Build round completed after 740 seconds. |
| 08:25:20 | rb-bluebot | Build Server message: Revision edd607c392 result: All green |
| 08:38:24 | | Join thanosengine [0] (~thanos@user/thanosengine) |
| 09:00 |
| 09:00:30 | | Quit thanosengine (Ping timeout: 246 seconds) |
| 09:15:46 | | Quit rogeliodh91 (Quit: The Lounge - https://thelounge.chat) |
| 09:16:08 | | Join rogeliodh91 [0] (~rogeliodh@rogeliodh.dev) |
| 09:24:01 | *** | Saving seen data "./dancer.seen" |
| 09:47:50 | | Quit reb (Quit: Connection closed) |
| 09:47:53 | speachy | reb: Generally we prefer the patch download but given how outdated that specific translation is, the full one is better. |
| 09:48:11 | speachy | the full one is also useful if you want to work on it offline |
| 09:52:25 | | Join reb [0] (~reb@80.208.34.77) |
| 09:56:43 | | Quit reb (Client Quit) |
| 10:00 |
| 10:56:24 | | Quit TorC (Ping timeout: 276 seconds) |
| 10:59:26 | | Join TorC [0] (~Tor@fsf/member/TorC) |
| 11:00 |
| 11:14:28 | | Join jj5_ [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au) |
| 11:14:58 | | Quit jj5 (Ping timeout: 248 seconds) |
| 11:15:02 | | Nick jj5_ is now known as jj5 (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au) |
| 11:23:35 | | Quit othello7 (Quit: othello7) |
| 11:24:03 | *** | Saving seen data "./dancer.seen" |
| 11:26:23 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 11:32:20 | | Join thanosengine [0] (~thanos@user/thanosengine) |
| 11:48:02 | | Quit ParkerR (Ping timeout: 248 seconds) |
| 11:56:58 | | Join ParkerR [0] (znc@znc.withg.org) |
| 12:00 |
| 12:00:52 | | Join Jinx [0] (~Jinx@user/jinx) |
| 12:06:27 | | Quit paulk (Ping timeout: 244 seconds) |
| 12:14:24 | | Join paulk [0] (~paulk@about/aquilenet/user/paulk) |
| 12:15:56 | | Quit thanosengine (Quit: WeeChat 4.3.1) |
| 12:16:34 | | Quit chamlis (Remote host closed the connection) |
| 12:17:02 | | Join chamlis [0] (~chamlis@user/chamlis) |
| 12:36:30 | OlsroFR | _bilgus: https://gerrit.rockbox.org/r/c/rockbox/+/5911 updated, ready to review. I changed the whole parsing logic with some more refactoring. I also tested on hardware to check for regressions, and all seems fine |
| 12:47:42 | | Quit OlsroFR (Ping timeout: 272 seconds) |
| 13:00 |
| 13:06:35 | | Join davisr [0] (~davisr@fsf/emeritus/davisr) |
| 13:24:06 | *** | Saving seen data "./dancer.seen" |
| 14:00 |
| 14:04:38 | spork | i think if you write g#5911 the bot will respond |
| 14:04:41 | rb-bluebot | Gerrit review #5911 at https://gerrit.rockbox.org/r/c/rockbox/+/5911 : Reworks to the shuffle system to improve performance and allow fast shuffling from a big library (but this work for all database views) by Paul Sauro |
| 14:14:51 | | Join halloy6399 [0] (~halloy639@aaubervilliers-198-1-21-253.w92-159.abo.wanadoo.fr) |
| 14:19:13 | | Quit halloy6399 (Changing host) |
| 14:19:13 | | Join halloy6399 [0] (~halloy639@user/OlsroFR) |
| 14:19:34 | | Quit halloy6399 (Remote host closed the connection) |
| 14:20:04 | | Join halloy6399 [0] (~halloy639@aaubervilliers-198-1-21-253.w92-159.abo.wanadoo.fr) |
| 14:20:32 | | Quit halloy6399 (Remote host closed the connection) |
| 14:21:34 | | Quit davisr (Quit: yeehaw) |
| 14:23:05 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 14:25:23 | | Join OlsroFR81 [0] (~OlsroFR@aaubervilliers-198-1-21-253.w92-159.abo.wanadoo.fr) |
| 14:25:28 | | Part OlsroFR81 |
| 14:25:59 | | Quit OlsroFR (Client Quit) |
| 14:26:28 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 14:32:05 | OlsroFR | Just tested to upload again my theme, still failing with error : "Disable main menu scrolling is not a allowed theme setting." |
| 14:35:41 | speachy | what happens when you run checkwps on the theme manually? |
| 14:37:20 | speachy | ah, I see, that's from a whitelist on the themesite itself.. |
| 14:38:15 | OlsroFR | Yeah. I just took a look on the tool "checkwps", he is not even able to check a .cfg file. Options are set only in the .cfg file, when you apply the theme |
| 14:45:07 | speachy | should work now |
| 14:45:31 | OlsroFR | my body is ready |
| 14:45:32 | speachy | ugh, this really shouldn't be part of the theme site. |
| 14:47:34 | OlsroFR | mmm I just upload my first theme but the result was a blank page |
| 14:47:38 | OlsroFR | is that intended ? |
| 14:48:22 | OlsroFR | I just uploaded Minimless for the iPods 1G to 4G |
| 14:49:51 | _bilgus | OlsroFR, that patch set looks much better 3 little things in it but I still don't like that 256k static alloc It'll be a few days before I can sit down and check it out but I'll look into doing an allocation from ram and see if that will work better |
| 14:50:54 | OlsroFR | Okay. I am going to look into your feedbacks and maybe try to understand by myself how to do it dynamically using RAM allocation |
| 14:53:10 | _bilgus | I wouldn't be against it so much if it wasn't fallow the rest of the time but as is thats like 15-20 seconds of playback on a mp3 permanently removed |
| 14:53:45 | _bilgus | core_alloc is the function for dynamic allocs |
| 14:53:55 | _bilgus | we don't use malloc |
| 14:54:42 | edhelas_ | What is the minimum amount of RAM that Rockbox can handle ? Is there some devices that have something like 32mb or less ? |
| 14:55:15 | _bilgus | 2 on the original clip |
| 14:55:29 | _bilgus | 8 on the clip+ zip fuzev1 v2 |
| 14:55:41 | _bilgus | I think the fuze+ is 32 |
| 14:55:59 | edhelas_ | Damn :D So those 256k are actually quite a lot |
| 14:56:04 | _bilgus | yes |
| 14:58:16 | _bilgus | I can't speak for everyone here but I really do try to think about others experiences when we add stuff like what percentage of users actually care about this versus the overhead everyone will get from it |
| 14:59:01 | _bilgus | like if its a global benefit then yes that makes sense |
| 14:59:25 | _bilgus | I like the patch set idea just hope we don't eat so much ram for it |
| 14:59:49 | OlsroFR | We can reduce that buffer the something lower like 64K. The code is protected against buffer overflow. But it will not go over 64000 tracks. But how many people in the community have more than 64K tracks ? ;) |
| 15:00 |
| 15:00:43 | OlsroFR | My whole music library is "just" around 25000 tracks currently |
| 15:01:30 | _bilgus | well if you look at the playlist code there is a max there too and I think I have somewhere north of 60000 in my db |
| 15:02:20 | OlsroFR | https://forums.rockbox.org/index.php/topic,52337.msg242319.html#msg242319 a person here claimed to have 65000 songs on his ipod classic lol |
| 15:02:56 | edhelas_ | Once I'll put the correct SD card I'll reach that, got something like 45000 songs |
| 15:03:07 | edhelas_ | Wondering how much time it will take to build the DB 😬 |
| 15:03:43 | OlsroFR | on my ipod mini it takes around 1 hour to build the database on device. But once it is built, it just work... until I want to add more songs ;) |
| 15:04:02 | OlsroFR | if you have the ipod classic 6th to 7th gen, it will be of course much faster because the CPU is much faster |
| 15:05:34 | edhelas_ | Would it maybe be interesting to have a tool to build it on the PC ? |
| 15:05:45 | speachy | it exists, though you have to compile it yourself. |
| 15:05:51 | speachy | ('dbtool') |
| 15:06:09 | OlsroFR | ah interesting. I was using the simulator to do that and it was just very slow |
| 15:06:11 | edhelas_ | Oh ! |
| 15:06:34 | spork | i thought i read the tool/sim did not work building the db 'because of endianess' |
| 15:06:52 | spork | on some forum post, so might be very wrong |
| 15:06:58 | _bilgus | the db is endian agnostic |
| 15:07:13 | spork | that would make that argument nonsense then |
| 15:07:22 | _bilgus | depends |
| 15:07:57 | _bilgus | something might be different between them still or mybe thats an old post |
| 15:08:32 | _bilgus | but unless your folder layout is the same.. |
| 15:09:54 | speachy | I don't know if are necessarily any differences in the on-disk db format between individual players, but the dbtool has _always_ been a per-target build instead of a generic tool. |
| 15:10:07 | speachy | so take that for what it's worth. |
| 15:10:18 | _bilgus | anyway OlsroFR if you figure something out before I get to it tahts fine or if we just can't figure a way around it maybe we can dial it back for the lower rm targets |
| 15:10:41 | _bilgus | lower ram* |
| 15:12:18 | _bilgus | depending on what contexts it'll be called in we might be able to steal the plylist buffer |
| 15:12:31 | _bilgus | sorry PLUGIN buffer |
| 15:12:49 | OlsroFR | Would be a very good compromise. I will need to take some time to do some research about this. |
| 15:13:05 | OlsroFR | But well let's be very carefull about stealing another buffer, this might create very weird bugs depending of the library size |
| 15:14:34 | _bilgus | that pretty much depends on if its exported to plugins and it very well may be and in that case we could require a buffer supplied by caller |
| 15:15:21 | _bilgus | the other option would be to fill a smaller buffer and when full randomly add anything that doesn't match |
| 15:17:05 | _bilgus | basically the buffer is full so if this new file isn't already here we do a rand and if it matches we add it anyway |
| 15:18:10 | OlsroFR | Mmm not sure to perfectly visualize your solution, but we need to be carefull to not add 2 times the same song. Right now the code is clever enough to never do this and pick really random songs all along the library by avoiding duplicates |
| 15:18:15 | | Quit Galois (Remote host closed the connection) |
| 15:18:54 | _bilgus | welland thats the downside of that solution if you run out of room you might get a double song |
| 15:21:16 | _bilgus | I wonder since our rand function is deterministic in regards to the seed you could actually throw away part of the field |
| 15:22:38 | _bilgus | you would just keep the number of iterations and you could trade time for space once you ran out |
| 15:24:09 | *** | Saving seen data "./dancer.seen" |
| 15:26:08 | OlsroFR | I will test different implementations and will test the impacts on hardware |
| 15:26:26 | _bilgus | basically you know the seed and now that the buffer is full you throw away the whole thing and fill it again once thats done you then cull entries by checking the output of rand with the original seed and to the numer of iterations |
| 15:28:17 | _bilgus | so lets say you had 100 entries they are all unique and added you throw aya the unique buffer and fill it with the next 100 entries that are all unique (to each other) and now you check against rand (run 100 times) |
| 15:28:42 | _bilgus | any that match you strike from the buffer |
| 15:29:02 | _bilgus | now the next 100 gets filled and check against rand(200x) |
| 15:29:58 | _bilgus | it will get exponentially slower so needs to be limited or at least cancel-able |
| 16:00 |
| 16:04:36 | OlsroFR | Dynamic allocation seems to work. I just found the constant AUDIO_BUFFER_RESERVE which seems to be the currrent reserve to store non-audio dynamic data |
| 16:04:59 | OlsroFR | which is, 256k, as you said, it can represents 20s of mp3 file |
| 16:06:19 | OlsroFR | what can be frustrating with it is that I have no control on it. If any other part of the code has taken some memory from it, allocation may fail completely |
| 16:08:30 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 16:08:45 | OlsroFR | this memory space is currently shared with the tagtree |
| 16:09:24 | OlsroFR | So I do not like the idea to take memory here |
| 16:13:57 | edhelas_ | Is it wise to have the same buffer on devices that have flash drive than HDD ? I mean the buffer and IO access is way faster with flash storage no ? |
| 16:33:22 | | Quit jacobk (Ping timeout: 248 seconds) |
| 16:38:46 | _bilgus | typically the devices with HDD have gobs of ram |
| 16:49:26 | _bilgus | OlsroFR as far as I can see the only tagtree function exported to plugins is tagtree_subentries_do_action() by the properties plugin |
| 16:51:22 | _bilgus | from what I can see it doesn't touch insert_all_playlist() so in theory you would be fine to take whatever is left of the plugin buffer (which could still be 0 we have TSR plugins that might choose not to give it up) |
| 16:51:28 | OlsroFR | _bilgus : initialize_tagtree is taking up space in the core buffer. Probably all time if you decide to keep it in RAM ? (which is the most optimized choice) |
| 16:53:25 | _bilgus | it shrinks it when its done |
| 16:54:13 | _bilgus | not sure why that matters though? |
| 17:00 |
| 17:02:32 | _bilgus | so i'm looking here https://gerrit.rockbox.org/r/c/rockbox/+/5911/3/apps/tagtree.c#2173 |
| 17:03:38 | _bilgus | not the codestyle is still different than the rest of the code but besides the point you have a check for playlist == NULL to do your randomizing |
| 17:04:09 | _bilgus | but you are reading from the current playlist and later writing them to the same playlist? |
| 17:04:26 | OlsroFR | I noticed that playlist is always NULL in the context of inserting from the tag database |
| 17:06:31 | _bilgus | well yeah because its the current playlist later https://github.com/Rockbox/rockbox/blob/master/apps/playlist.c#L2625 |
| 17:09:13 | _bilgus | no nevermind you are just pulling the maxsize from it not the actual indices |
| 17:14:22 | _bilgus | OlsroFR, I think with the way this is set up you could actually just look if max_available_space is too small and randomly skip indices |
| 17:15:32 | OlsroFR | _bilgus this way it will not be truly random; I have thought about this. The issue with true random skipping is that the playlist will grow until the limit and stop growing when the limit will be reachen. |
| 17:15:55 | OlsroFR | Because of this behavior, by doing this way, this "randomness" will tend to "random" only the first tracks |
| 17:16:38 | OlsroFR | Exemple : If you have a system limit of 2000 and you put 50% of chances to skip the current index, it means that statically you will get true randomness only between the first 4000 songs of your library |
| 17:18:16 | _bilgus | tag_cache_retrieve will return whatever indice you choose |
| 17:19:13 | OlsroFR | Ah I get what you mean. That was my first try on developing this. From what I can remember, for a reason that I don't know, the performance was very very slow |
| 17:19:16 | _bilgus | if you know that there is not enough room ahead of time if you choose to skip every 0-6 songs you effectively have a random playlist still and a larger sampling of the whole library |
| 17:19:20 | OlsroFR | Also, another issue is that you may get duplicates |
| 17:19:49 | _bilgus | you will get duplicates anyway thats why it has a uniqbuf |
| 17:20:21 | OlsroFR | right now with the current system there is no possible duplicates, it's checking for it, look in the while (true) loop |
| 17:20:41 | OlsroFR | (with what I developed and pushed for review) |
| 17:20:50 | _bilgus | sure but you have reinvented the uniq buf with a fallow buffer |
| 17:21:38 | OlsroFR | I wanted something perfect just like the Stock OS can do about this feature. When you mix your library on Stock OS, you never get duplicates |
| 17:22:20 | _bilgus | you don't get duplicates currently either not disputing that |
| 17:23:09 | _bilgus | retrieve_entries already does this |
| 17:24:11 | *** | Saving seen data "./dancer.seen" |
| 17:24:50 | _bilgus | so all you need to do is make sure theres enough uniqbuf and skip a random amount between 0 and n and you need to insure n isn't so large that you don't have enough entries left |
| 17:26:07 | OlsroFR | noted |
| 17:26:53 | _bilgus | not saying i'm not wrong but i'm pretty sure this will do what you want with minimal extra overhead (might increase uniqbuf) |
| 17:27:38 | _bilgus | but thats fine atleast it has 2 users |
| 17:30:08 | OlsroFR | I am still currently coding something, I feel like I am following the good path. I will push it for review when it will be done |
| 17:30:12 | OlsroFR | probably in one hour or two |
| 17:31:49 | _bilgus | I'm headed out but i'll check back later this eve I check gerrit so just make sure you use −−amend and I'll see it |
| 17:38:44 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 19:00 |
| 19:08:18 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 19:24:15 | *** | No seen item changed, no save performed. |
| 19:56:03 | | Join massiveH [0] (~massiveH@2600:4040:a982:dc00:38d6:2ca9:2d4f:f66b) |
| 21:00 |
| 21:24:19 | *** | No seen item changed, no save performed. |
| 22:00 |
| 22:05:25 | dconrad | _bilgus I like the idea of the HAVE_BOOTDATA option, I feel like this could be useful to other ports in the future without much work |
| 22:05:40 | dconrad | It appears to work as promised |
| 22:11:45 | | Quit Moriar (Ping timeout: 276 seconds) |
| 22:15:36 | OlsroFR | _bilgus https://gerrit.rockbox.org/r/dashboard/self new patches submitted. It was tought, I am now tired, but happy. Reduced the memory consumption to divide it by 256 basically ;) |
| 22:17:18 | OlsroFR | I didn't use the dynamic buffer, for so little space it just do not worth it anymore and might cause issues since there is yield() and the core buffer is not recommended to use in this case. I also fixed some bugs. I've did many hours of coding and testing. I am going to sleep now. |
| 22:19:43 | OlsroFR | With this system of segments, the random is slightly less random especially for the last segment that is processed. It's the very little compromise of this patch. But it should be more than good enough for the use case |
| 22:20:04 | | Quit OlsroFR (Quit: Connection closed) |
| 22:39:49 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 22:40:05 | | Quit OlsroFR (Client Quit) |
| 22:49:09 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 22:49:30 | OlsroFR | I could finally successfully upload my 4 themes, thanks again for the help! I am so happy to share those |
| 22:49:57 | OlsroFR | https://themes.rockbox.org/index.php?target=ipodmini2g https://themes.rockbox.org/index.php?target=ipod4g |
| 22:50:54 | | Quit OlsroFR (Client Quit) |
| 23:00 |
| 23:22:11 | | Quit massiveH (Quit: Leaving) |
| 23:24:21 | *** | Saving seen data "./dancer.seen" |
| 23:43:15 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
icon identifies that the person is a core developer (has commit access).