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 2020-12-09

00:51:45saratogaalso, bmp.h uses signed shorts for dimensions, so any jpeg or bmp with >= 32768 pixels width will overflow and try to resize to a negative value
01:17:41 Quit saratoga (Remote host closed the connection)
01:47:34***Saving seen data "./dancer.seen"
02:07:57 Join Rower [0] (
02:32:14 Join petur [0] (~petur@
02:32:14 Quit petur (Changing host)
02:32:14 Join petur [0] (~petur@rockbox/developer/petur)
02:37:11 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
02:41:04braewoodsspeachy: i was looking for other old mp3 players that might be viable to write new ports for.. the main ones i was looking at are the philips hdd units since you can dig up their old schematics which would make writing ports much easier.
02:41:27braewoodsthough i found one series, hdd08x
02:41:30braewoods... but
02:42:01braewoodsthey used a type of HDD interface that was essentially proprietary; specific to the ancient cornice drives that have since ceased to exist
02:42:19braewoodsso repairability is nearly 0 even with viable battery replacements
02:42:51braewoodsstrange world these old electronics were in
02:43:09braewoodsa window where HDDs were more practical than flash for raw storage size
02:43:19braewoodsin a small package
03:38:22 Join edhelas [0] (
03:45:47 Quit asaba (Quit: Relay server offline)
03:45:58 Join asaba [0] (~asaba@
03:47:37***Saving seen data "./dancer.seen"
03:53:19 Join JanC [0] (~janc@lugwv/member/JanC)
03:55:58 Quit S|h|a|w|n (Read error: Connection reset by peer)
05:45:35 Join MrZeus [0] (
05:47:39***Saving seen data "./dancer.seen"
05:49:42 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
05:54:40 Quit Stanley00 ()
07:15:56 Quit edhelas (Remote host closed the connection)
07:20:37 Quit Galois (Ping timeout: 260 seconds)
07:47:42***Saving seen data "./dancer.seen"
08:51:58 Join edhelas [0] (9d94237298@2a01:7c8:aab8:6b9:5054:ff:fec9:fd84)
08:57:38 Join massiveH [0] (
09:06:04 Quit Strife89 (Quit: No Ping reply in 180 seconds.)
09:07:40 Join Strife89 [0] (
09:20:20 Part edhelas
09:21:20 Join edhelas [0] (
09:24:13 Quit kirvesAxe (Ping timeout: 264 seconds)
09:24:25 Join kirvesAxe [0] (
09:31:45 Join Galois [0] (
09:39:13 Quit Misanthropos (Read error: Connection reset by peer)
09:39:29 Join Misanthr- [0] (~Misanthro@
09:40:50 Nick Misanthr- is now known as Misanthropos (~Misanthro@
09:46:31 Quit MrZeus (Read error: Connection reset by peer)
09:47:46***Saving seen data "./dancer.seen"
09:56:07 Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:7c07:2f55:590e:4b6)
10:07:29 Join prof_wolfff [0] (
10:19:30 Quit massiveH (Quit: Leaving)
11:01:51 Join jdarnley [0] (
11:03:16 Quit J_Darnley (Ping timeout: 240 seconds)
11:14:48 Quit edhelas (Remote host closed the connection)
11:18:32 Quit beencubed (Ping timeout: 256 seconds)
11:33:15 Join saratoga [0] (
11:34:00 Join beencubed [0] (~beencubed@
11:47:50***Saving seen data "./dancer.seen"
12:00:36 Quit petur (Quit: Connection reset by beer)
12:41:12saratogais anyone familiar with playback.c? i'd like to change the fail logic when buffering album art
12:43:53speachyby all means, go for it!
12:45:52 Quit Moarc (Read error: Connection reset by peer)
12:50:30 Join Moarc [0] (
12:56:03saratogai have a well earned fear of playback.c
12:56:16speachywhat's the worst that can happen?
13:01:23saratogaif I'm using the command line git app, and pushing a commit message to gerrit, am I supposed to 80 line wrap the commit message or does git do that as appropriate for me?
13:01:52speachyit won't alter it in any way; just warns about it.
13:02:50saratogacan I set the nano editor to wrap it for me?
13:03:44speachy(I set EDITOR to 'nano -t -r 72')
13:05:46saratogawhy 72 and not 80?
13:07:56speachyI forget why now. I've had that set for a loooong time now
13:10:16saratogai think i just amended my new playback.c changes to my previous commit that was pushed to gerrit while trying to change the text wrapping
13:10:36saratogawhat is the command the see what files a previous commit changed? git log doesn't seem to show it
13:10:41speachygit log −−stat
13:11:29saratogaok, so i can amend that commit again btu how do i remove playback.c from it?
13:13:37speachygit rebase -i, edit the commit in question
13:14:13speachythen git reset −−soft commitid_you_want filename
13:14:23speachythen git rebase −−continue
13:14:26speachy(more or less)
13:23:31saratogaok, pushed to gerrit:
13:34:12speachyare there adverse side effects to audio_load_albumart()?
13:40:28 Join lebellium [0] (
13:41:22saratogaspeachy: under normal circumstances (buffer is merely full) it'll be called repeatedly until the file fits, so I don't think so
13:42:01saratogai don't see anything either, but yeah this is why messing with buffering is a nightmare
13:43:56saratogai tried it on a big and a small buffer simulator and it fixed playback deadlocks if the album art was larger than the buffer
13:44:04saratogamore testing would be nice though
13:44:41saratogai guess the case it could make worse would be album art that fits in buffer, but just barely (so it might take multiple tries)
13:44:59saratogaanything else is either not effected or already a crash in git
13:47:51***Saving seen data "./dancer.seen"
14:34:10saratogatesting with some huge files that almost don't fit, the downside of this fix is that sometimes the album art is skipped because the audio is buffered in the remaining space, so the album art load is never tried again
14:35:34speachyhmm. It ought to be straightforward to behave differently between "not enough free space" and "artwork requires more space than will ever be available"
14:35:41 Quit michaelni (Quit: Leaving)
14:36:06speachy(that threshold IMO shouldn't exceed ~80% of the buffer. ish...)
14:36:13 Join michaelni [0] (
14:37:16saratogayes, that would make more sense
14:37:20saratogai need to look at how best to do that
14:45:31saratogathe annoying thing is that the bufferlib api just tells you that adding a file to the buffer failed, but it doesn't tell you if it failed because the buffer was full or if it failed because the file was bigger than the buffer
15:05:12speachyand the rabbit hole opens up. :)
15:09:15saratogaI could make bufopen return a new error type instead of ERR_BUFFER_FULL when the buffer isn't full but the file is larger than the buffer
15:09:41saratogabut there are a lot of checks in the code for ERR_BUFFER_FULL which might fail in that case
15:10:17saratogai could restrict the new error to just album art allocations, but that seems hacky
15:11:01saratogaalso we have a radioart.c ???
15:12:58saratogamaybe a new error type called ERR_BITMAP_LARGER_THAN_BUFFER that can only be generated when trying to allocate bitmaps would be safest
15:13:15saratogathere are only two functions in rockbox that try to allocate bitmaps on the buffer
15:13:22saratogai think
15:14:35saratogayes that is true
15:47:52***Saving seen data "./dancer.seen"
16:26:57saratogatesting in the simulator, this actually seems to work pretty well, switching rapidly between large embedded and folder.jpg album art, I can't get any of the images to fail to load or for playback to deadlock
16:27:23saratoganow i need to figure out why the current cross compilers aren't building on window 10 SFU and try on a real device
17:26:22 Quit pamaury (Ping timeout: 260 seconds)
17:44:25 Quit lebellium (Quit: Leaving)
17:47:56***Saving seen data "./dancer.seen"
18:02:23 Join ac_laptop [0] (~ac_laptop@
18:02:51 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
18:43:25 Quit SammysHP (Quit: *wuff*)
18:43:37 Join SammysHP [0] (
19:06:05 Quit SammysHP (Quit: *wuff*)
19:06:23 Join SammysHP [0] (
19:29:32 Quit toruvinn (Ping timeout: 260 seconds)
19:29:38 Join toruvinn [0] (
19:37:34 Quit saratoga (Remote host closed the connection)
19:48:00***Saving seen data "./dancer.seen"
20:23:43_bilgus_oh saratoga (logs) nice −− this is a long standing bug
21:08:17 Quit MrZeus (Ping timeout: 258 seconds)
21:12:24 Join MrZeus [0] (MrZeus@gateway/vpn/mullvad/mrzeus)
21:18:38 Quit prof_wolfff (Ping timeout: 258 seconds)
21:48:01***Saving seen data "./dancer.seen"
21:52:03 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
22:12:04 Quit ac_laptop (Ping timeout: 256 seconds)
22:21:50 Quit Romster (Ping timeout: 272 seconds)
22:26:07 Join Romster [0] (~romster@unaffiliated/romster)
22:40:43fs-bluebot_Build Server message: New build round started. Revision c07c08506b, 293 builds, 9 clients.
22:53:56fs-bluebot_Build Server message: Build round completed after 793 seconds.
22:53:58fs-bluebot_Build Server message: Revision c07c08506b result: All green
22:54:54 Join ac_laptop [0] (~ac_laptop@
23:34:53fs-bluebot_Build Server message: New build round started. Revision d99320047c, 293 builds, 9 clients.
23:46:19fs-bluebot_Build Server message: Build round completed after 687 seconds.
23:46:21fs-bluebot_Build Server message: Revision d99320047c result: All green
23:47:38fs-bluebot_Build Server message: New build round started. Revision 52d437b33e, 293 builds, 9 clients.
23:48:05***Saving seen data "./dancer.seen"
23:49:05 Quit TheSeven (Disconnected by services)
23:49:14 Join [7] [0] (~quassel@rockbox/developer/TheSeven)
23:52:56 Quit ac_laptop (Ping timeout: 240 seconds)
23:58:21fs-bluebot_Build Server message: Build round completed after 643 seconds.
23:58:23fs-bluebot_Build Server message: Revision 52d437b33e result: All green

Previous day | Next day