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 2022-03-28

00:04:00***Saving seen data "./dancer.seen"
00:35:45 Quit berber (*.net *.split)
00:35:49 Quit SammysHP (*.net *.split)
00:36:21 Join berber [0] (
00:36:28 Join SammysHP [0] (
02:04:03***Saving seen data "./dancer.seen"
03:19:46 Quit paulcarroty (Quit: Bridge terminating on SIGTERM)
03:19:46 Quit MayeulC (Quit: Bridge terminating on SIGTERM)
03:19:47 Quit TimeWalker[m] (Quit: Bridge terminating on SIGTERM)
03:19:51 Quit blbro[m] (Quit: Bridge terminating on SIGTERM)
03:24:00 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
03:31:20 Join paulcarroty [0] (~paulcarro@2001:470:69fc:105::216)
03:31:20 Join MayeulC [0] (~mayeulc@2001:470:69fc:105::35e)
03:31:20 Join TimeWalker[m] [0] (~timewalke@2001:470:69fc:105::d4f)
04:04:07***Saving seen data "./dancer.seen"
06:04:09***No seen item changed, no save performed.
07:05:11 Quit paulcarroty (Quit: User was banned)
07:05:11 Quit MayeulC (Quit: User was banned)
07:05:17 Quit blbro[m] (Quit: User was banned)
07:05:49 Quit TimeWalker[m] (Quit: User was banned)
07:12:40 Quit kop316 (Remote host closed the connection)
08:04:13***Saving seen data "./dancer.seen"
08:08:44 Join Maxdaman1us [0] (~Maxdamant@user/maxdamantus)
08:08:47 Quit Maxdamantus (Ping timeout: 260 seconds)
08:11:03 Nick Maxdaman1us is now known as Maxdamantus (~Maxdamant@user/maxdamantus)
08:44:22 Join massiveH [0] (
08:49:14 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
08:57:21 Join paulcarroty [0] (~paulcarro@2001:470:69fc:105::216)
08:57:21 Join MayeulC [0] (~mayeulc@2001:470:69fc:105::35e)
08:57:21 Join TimeWalker[m] [0] (~timewalke@2001:470:69fc:105::d4f)
09:51:46_bilgusResearching the landscape of wheels already invented I found Q3VM a bytecode virtual machine, I'm not sure if its going to work in core but I've already got it up and running as a plugin
10:04:16***Saving seen data "./dancer.seen"
10:31:30 Quit massiveH (Quit: Leaving)
10:59:56 Join chris_s [0] (
11:18:40chris_s_bilgus: re this commit: Is waiting for the dircache really always necessary when resuming the playlist – at least with root direct disabled?
11:18:48chris_sOn the surface, everything seems to work fine without that line in my own build and it would be nice to shave off a few seconds of loading time when you want to play something right away. Maybe I just haven't run into the scenario where relative paths are used?
11:29:14 Quit chris_s (Quit: Connection closed)
11:43:25 Quit dys (Remote host closed the connection)
11:47:59 Join bilgus_ph [0] (~bilgus_ph@
11:48:09 Join dys [0] (~dys@user/dys)
11:52:15bilgus_phChris_s I want to say yah go ahead but tbh I'm not sure since before the buffer just got stolen underneath it I think now it probably needs to get done before there is no buffer left otherwise you will have it work fine till you get to an entry that didn't get thrown into the cache and a deadlock waiting for it
11:53:09bilgus_phBut that's not to say I,'m wrong surely isn't the first time
11:56:17bilgus_phOr rather not wrong;)
11:56:37 Quit bilgus_ph (Quit: Connection closed)
12:04:17***Saving seen data "./dancer.seen"
13:03:20 Join lebellium [0] (
13:49:56 Quit rogeliodh (Quit: The Lounge -
13:50:22 Join rogeliodh [0] (
14:04:19***Saving seen data "./dancer.seen"
16:04:21***No seen item changed, no save performed.
16:55:56 Join chris_s [0] (
16:58:34chris_shm ok, thanks! I didn't realize that...  :/
17:02:59_bilguswhat highlighted the issue for me was having > 20000 files and a random playlist, what you can do to test is make a bunch of copies of what you already have on there into a separate folder start from a clean build dir (or delete tagcache/databas/nvram files) then point the db there to generate and try with a fresh random playlist
17:04:51_bilgusI found it most consistently on boot and having start screen set to resume
17:05:31_bilgusI can try tonight running from internal to see if I fail to reproduce it
18:04:22***No seen item changed, no save performed.
18:05:25 Quit lebellium (Quit: Leaving)
19:34:47 Quit chris_s (Ping timeout: 260 seconds)
19:50:36 Quit Malinux (Ping timeout: 240 seconds)
20:03:16 Join bilgus_ph [0] (~bilgus_ph@
20:04:25***Saving seen data "./dancer.seen"
20:04:57 Join Malinux [0] (~malin@2001:4641:4dfa::12c:c4a7)
20:05:26bilgus_phChris_s yes I can confirm it still happens on internal drive too one song might resume in 10 seconds so far I'm up to 1.5 mins for the longest I've waited to resume
20:07:30bilgus_phI'm sure given enough tries I can get even longer delays, I think before dircache could silently steal the buffer out from under the playlist and most of the time give it back before someone caught it
20:08:44bilgus_phI'm sure we could probably rewrite them to share more effectively to solve it
20:14:20bilgus_phMy crazy plan atm is to try putting as much one time code into a bytecode file and load it the throw it away and then I would like to see about rescuing the vm to run plugins that can be moved by the buflib, then I could see farming out the configuration stuff too it could still be in ram for quick access but could be dumped and reloaded later when
20:20:08bilgus_phBut so far I still have a lot to do to even get rbox core compiling bytecode
20:20:36 Quit bilgus_ph (Quit: Connection closed)
20:21:56 Quit rb-bluebot (Quit: connection lost?)
20:22:04 Join rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility)
20:41:51 Quit hook54321 (Ping timeout: 250 seconds)
20:43:48 Join hook54321 [0] (sid149355@user/hook54321)
21:11:19 Quit vup (Ping timeout: 250 seconds)
21:11:34 Join vup [0] (~~~~@
22:04:27***Saving seen data "./dancer.seen"
23:00:52 Quit skipwich_ (Quit: DISCONNECT)
23:02:10 Join skipwich [0] (~skipwich@user/skipwich)

Previous day | Next day