Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2025-05-26

00:21:07 Quit Nyaa (Quit: Ping timeout (120 seconds))
00:21:53 Join Nyaa [0] (~Nyaaori@cyberia.club/meow/nyaaori)
00:22:19 Quit troglodito (Ping timeout: 252 seconds)
00:24:12 Join troglodito [0] (~cave@81.4.123.134)
00:45:23 Join chris_s [0] (~chris_s@2a02:26f7:ec5c:4000:2800::1c)
00:54:10 Quit JanC (Ping timeout: 248 seconds)
00:56:04 Join JanC [0] (~janc@user/janc)
00:57:43chris_s_bilgus: I've noticed that when the voice engine has to spell out strings exceeding QUEUE_SIZE (currently set at 64), the UI becomes completely unresponsive.  Which I tracked down to a busy loop on the UI thread: https://git.rockbox.org/cgit/rockbox.git/commit/?id=3b1230b . In case of longer comment tags or even classical music titles, the time
00:57:44chris_swhere no interaction is possible can be quite significant.
00:58:06chris_sI wonder if it isn't preferable to only partly voice such strings instead, as before, or was that a tradeoff you had considered? Can we possibly increase QUEUE_SIZE a bit instead?
01:00
01:00:41 Quit JanC (Ping timeout: 252 seconds)
01:03:03 Join JanC [0] (~janc@user/janc)
01:20:39 Quit chris_s (Quit: Client closed)
01:24:46 Quit melmothX (Quit: reboot)
01:42:58***Saving seen data "./dancer.seen"
02:00
02:23:38 Join melmothX [0] (~marco@amusewiki/marco)
02:28:34 Quit massiveH (Quit: Leaving)
03:00
03:21:57 Quit thanosengine (Remote host closed the connection)
03:22:20 Join thanosengine [0] (~eden@user/thanosengine)
03:41:52 Quit Maxdamantus (Ping timeout: 265 seconds)
03:42:59***Saving seen data "./dancer.seen"
04:00
04:07:06 Quit JanC (Killed (tantalum.libera.chat (Nickname regained by services)))
04:07:11 Join JanC [0] (~janc@user/janc)
04:45:27 Quit PheralSparky (Read error: Connection reset by peer)
05:00
05:43:03***Saving seen data "./dancer.seen"
05:45:08 Join Maxdamantus [0] (~Maxdamant@user/maxdamantus)
07:00
07:43:05***No seen item changed, no save performed.
08:00
08:26:31 Part paulcarroty
09:00
09:43:09***Saving seen data "./dancer.seen"
09:44:04 Nick braewoods_ is now known as braewoods (~braewoods@user/braewoods)
10:00
10:08:14_bilguschris_s barring a user abort loop, pretty much the only option is to increase queue or deal with cut off words
10:12:14_bilgusotherwise isn't partially voicing such strings is just trading one bug for another depending on which sense you deem more valuable?
10:25:16_bilgusanother option might be to speed up the voicing in these situations
10:32:08 Join bahusoid [0] (~bahusoid@91.215.146.97)
10:35:21bahusoid> barring a user abort loop
10:35:37bahusoidbreaking this busy loop in case of any user actions looks like good option to me
10:37:41 Quit bahusoid (Quit: Client closed)
10:55:35_bilgusprobably as long as the overhead of the abort doesn't make it too slow but that should be minimized that since its only when exceeding the queue
11:00
11:20:59speachyfwiw I think it's more reasonable to truncate the spelling-out.
11:21:42speachywhere this is a problem is filenames, and there's not really a way to "Abort" reading those out.
11:23:49speachy(well, short of simply scrolling to another one)
11:25:21speachyso unless "Breaking out of busy loop" is "any input whatsoevere"..
11:26:44speachyfilenames and database metadata. The latter of which I still want to add talkclips for.
11:27:39braewoodsTis a shame we can't just throw more RAM at these random issues.
11:27:44_bilgusyeah likely any button press should be construed as breaking from the loop otherwise you'd need an abort action like the back btn
11:29:22speachywell, making the queue size larger _is_ throwing RAM at it, but if you consider the nature of this problem, we'd have to make the queue size capable of handling a max-length filename (255 characters)
11:30:11braewoodsso quadrupling the current size.
11:30:30speachy(and metadata effectively has no upper limit with elements being potentially multiple megabytes.
11:30:52braewoodsYea but unlikely a text string will be that super long. just doubling to 128 might be enough.
11:31:17speachy(ID3v1 is 30 bytes per field)
11:31:53braewoodsspeachy, regardless of actual data length?
11:32:34_bilgusget_action_statuscode allows checking the last button
11:33:06speachymax length of an ID3v2 tag is the frame size, 16MB. max combined size is 256MB.
11:35:04speachyID3v1 is really simple, sony, artist, albun, comment are 30 bytes each, plus a couple extra fields, for a fixed total of 128B.
11:35:14speachys/sony/song/
11:35:42_bilgusyou could probably just check !SYS and everything else skips the speech
11:43:12***Saving seen data "./dancer.seen"
12:00
12:45:41 Join lebellium [0] (~lebellium@2a01cb0405d03a004070cdf0d3f7e170.ipv6.abo.wanadoo.fr)
12:46:50 Quit desowin (Ping timeout: 260 seconds)
13:00
13:40:12 Join desowin [0] (~desowin@rockbox/developer/desowin)
13:43:13***Saving seen data "./dancer.seen"
15:00
15:43:17***No seen item changed, no save performed.
17:00
17:30:44 Nick thanosengine is now known as eden (~eden@user/thanosengine)
17:38:14 Quit eden (Quit: WeeChat 4.6.1)
17:43:19***Saving seen data "./dancer.seen"
17:44:49 Quit lebellium (Quit: Leaving)
18:00
18:22:19 Join thanosengine [0] (~eden@user/thanosengine)
18:36:52 Quit thanosengine (Quit: WeeChat 4.6.1)
18:37:25 Join thanosengine [0] (~eden@user/thanosengine)
19:00
19:28:53 Quit dbohdan (Quit: ZNC 1.8.2+deb3.1 - https://znc.in)
19:30:24 Join dbohdan [0] (~dbohdan@user/dbohdan)
19:35:29 Join joel|2 [0] (~kvirc@189.146.185.56)
19:42:06joel|2hello everyone, any update on this merge request https://gerrit.rockbox.org/r/c/rockbox/+/6031, i think is a very usefull feature and adds a lot to the rockbox experience
19:43:23***Saving seen data "./dancer.seen"
19:56:52 Join massiveH [0] (~massiveH@108.50.181.86)
20:00
20:08:44 Quit COMPL_EXE (Read error: Connection reset by peer)
20:09:07 Join COMPL_EXE [0] (~compl.exe@aosc/dev/origincode)
20:09:27 Quit meatloaf (Remote host closed the connection)
20:09:45 Join meatloaf [0] (~meatloaf@c-76-157-247-204.hsd1.il.comcast.net)
21:00
21:06:39 Quit joel|2 (Ping timeout: 245 seconds)
21:28:21 Quit pixelma (Ping timeout: 248 seconds)
21:28:45 Join pixelma [0] (marianne@p200300ea87161400305e95fffec66ff3.dip0.t-ipconnect.de)
21:37:19 Quit dbohdan (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in)
21:38:52 Nick JanC is now known as Guest6826 (~janc@user/janc)
21:38:52 Quit Guest6826 (Killed (lead.libera.chat (Nickname regained by services)))
21:38:56 Join JanC [0] (~janc@user/janc)
21:43:24***Saving seen data "./dancer.seen"
21:43:40 Join dbohdan [0] (~dbohdan@user/dbohdan)
23:00
23:06:33 Join thanosen1 [0] (~eden@user/thanosengine)
23:31:29 Join chris_s [0] (~chris_s@2a09:bac3:2bce:248c::3a4:6)
23:33:16 Quit massiveH (Quit: Leaving)
23:41:24chris_sthanks, I've uploaded a possible solution that checks for a button press, which keeps the UI responsive. Not super happy with the fact that it swallows the button press in that case, but certainly a lot better than before.  Unsure if QUEUE_SIZE should still be doubled, simply to have the situation occur less frequently; the effect on RAM usage
23:41:24chris_sseems pretty limited. IDK how many people are actuallly prepared to wait for so many characters being spelled out at that point.
23:41:48chris_s(g6566)
23:43:25***Saving seen data "./dancer.seen"

Previous day | Next day