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 2024-10-06

00:02:14 Quit massiveH (Read error: Connection reset by peer)
00:04:34 Join massiveH [0] (~massiveH@2600:4040:a982:dc00:2812:504f:675:c6f5)
00:57:59 Quit massiveH (Quit: Leaving)
01:00
01:42:54***Saving seen data "./dancer.seen"
02:00
02:49:43 Join PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647)
03:00
03:42:58***No seen item changed, no save performed.
04:00
04:11:56 Quit PheralSparky (Quit: Leaving)
04:18:34 Join lebellium [0] (~lebellium@2a01cb0405d07f0010775b581efb68ef.ipv6.abo.wanadoo.fr)
05:00
05:04:24 Quit jacobk (Ping timeout: 260 seconds)
05:05:27 Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net)
05:12:41 Quit Bobathan_ (Ping timeout: 252 seconds)
05:39:03 Join Bobathan [0] (~admin@syn-065-029-248-157.res.spectrum.com)
05:43:02***Saving seen data "./dancer.seen"
07:00
07:43:03***No seen item changed, no save performed.
09:00
09:11:24 Quit Bobathan (Ping timeout: 246 seconds)
09:12:19 Join Bobathan_ [0] (~admin@syn-065-029-248-157.res.spectrum.com)
09:30:50rb-bluebotBuild Server message: New build round started. Revision 2f3b9ab68a, 345 builds, 10 clients.
09:30:50rb-bluebottms320dm320: Correct a warning with newer toolchains by Solomon Peachy
09:32:04 Quit Bobathan_ (Ping timeout: 245 seconds)
09:42:03 Join Bobathan_ [0] (~admin@syn-065-029-248-157.res.spectrum.com)
09:43:07***Saving seen data "./dancer.seen"
09:44:53rb-bluebotBuild Server message: Build round completed after 844 seconds.
09:44:55rb-bluebotBuild Server message: Revision 2f3b9ab68a result: All green
10:00
10:15:31 Quit rb-bluebot (Remote host closed the connection)
10:15:44 Join rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility)
10:20:38 Quit rb-bluebot (Quit: connection lost?)
10:36:48 Join rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility)
10:45:57 Join chris_s [0] (~chris_s@2a02:8071:67a1:f60:153c:f9f7:870c:ca35)
11:00
11:12:53 Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net)
11:43:08***Saving seen data "./dancer.seen"
12:00
12:33:42 Quit Bobathan_ (Ping timeout: 246 seconds)
12:37:37 Join Bobathan [0] (~admin@syn-065-029-248-157.res.spectrum.com)
13:00
13:43:11***Saving seen data "./dancer.seen"
13:56:01_bilgusSO I'm still messing around witht this ram disk idea I think its interesting but it sure is getting complicated, I think I may just try re-implementing some fore of in-ram control file with less code overall
13:57:17_bilgusjust to get the the thing up I have to carry around the first sectors of a blank format in the code too
13:58:29_bilgusso I'm thinking about a few ideas one adding a callback to plugin_get_buffer() to allow flushing to disk if something wants the buffer
14:00
14:53:15 Quit jacobk (Ping timeout: 276 seconds)
14:53:50 Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net)
15:00
15:01:20 Quit cnx (Ping timeout: 272 seconds)
15:06:05 Join cnx [0] (~cnx@tem.loang.net)
15:42:30user890104_bilgus: what ram disk idea?
15:43:07user890104i was struggling with STORAGE_RAMDISK a few months ago
15:43:12***Saving seen data "./dancer.seen"
15:51:43_bilgusI applied the plugin buffer as the backend but you have to have proper data in there
15:52:41_bilgusbasically what I wanted to do was give the user a way to build the file directly in ram
15:53:55_bilgusbut I'm at 3k just getting a disk working and it still needs lots of support code
15:54:32_bilgusI think I can probably do better with a less general approach
15:56:13_bilgusI started with trying to link the file cache to the plugin buf which worked but didn't stop disk writes and increased the complexity a lot for the modest speed increase it gave
15:57:53_bilgussorry the reason was for when playing folders you have disk writes for the control file which is slower and results in useless disk writes that may not even be needed
15:58:19_bilgusso I figured I'd explore adding the in-ram part to the backend
15:59:17_bilguslike you could just create the file on a ramdisk and flush it to disk if the space is needed or just dump it and rewrite if not
16:00
16:03:26_bilgusinstead we could use the pluginbuf as file buffer give a callback for the pluginbuf to notify us when our data is threatened (and the disk is probably being used to load a plugin) and write the control file then this would serve to speed up the building of the playlist and cut down on writes and rewrites to the disk
16:08:25_bilgusIdk I'm just exploring the options here, I really don't see too many issues with what we have currently. Its a whole lot more stable than what we had before but I saw some rumblings from a few on the forum and FS not liking it
16:44:12user890104isn't the control file actually some struct that's serialized to a file?
16:51:00_bilgus its structured data basically the command file spells out PLAYLIST_ADD INSERT FIRST FILE.MP3
16:52:07_bilgusA:0:0:01 - AFILE.flac
16:52:34_bilgus^ thats the same thing in control file speak
16:55:09_bilgusso the idea with the control file is starting from a baseline state you only save changes to the playlist in the control file later you can reboot start from the same baseline and apply those changes again
16:55:42_bilgusthis is to reduce the rewriting of whole playlists
16:57:55_bilgusnow that the playlist code has been unified when you play a directory the control file becomes a bunch of those add commands for the whole directory which works but has to be written to disk each time you select another track in a new directory
17:00
17:00:13_bilgusmy other thought is to just save the directory playlist when its accessed and that will make the control file not be used (next time) but then it becomes a versioning problem now we have to keep track of added and deleted files
17:08:23 Quit lebellium (Quit: Leaving)
17:43:14***Saving seen data "./dancer.seen"
17:56:24 Quit drew (Ping timeout: 244 seconds)
18:00
18:04:43 Join drew [0] (~drew@user/drew)
19:00
19:23:15 Quit chris_s ()
19:29:11 Quit Bobathan (Ping timeout: 265 seconds)
19:33:39 Join Bobathan [0] (~admin@syn-065-029-248-157.res.spectrum.com)
19:43:16***Saving seen data "./dancer.seen"
19:47:19 Join massiveH [0] (~massiveH@2600:4040:a982:dc00:2d08:be00:d189:e24a)
21:00
21:01:33 Quit jn (Ping timeout: 252 seconds)
21:07:22 Join jn [0] (~quassel@2001-4dd4-85df-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de)
21:07:23 Quit jn (Changing host)
21:07:23 Join jn [0] (~quassel@user/jn/x-3390946)
21:13:06 Quit jn (Ping timeout: 252 seconds)
21:13:17 Join jn [0] (~quassel@2001-4dd4-883c-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de)
21:13:18 Quit jn (Changing host)
21:13:18 Join jn [0] (~quassel@user/jn/x-3390946)
21:43:18***Saving seen data "./dancer.seen"
22:00
22:27:28 Quit Moriar (Quit: Leaving.)
22:44:19 Quit massiveH (Quit: Leaving)
23:00
23:43:21***Saving seen data "./dancer.seen"

Previous day | Next day