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 2021-07-30

00:48:52_bilgus g#3627
00:48:54rb-bluebotGerrit review #3627 at : playlist.c fix multitude of sins Invalid Control file on USB unplug? by William Wilgus
00:49:15_bilgusThat is an OLD very annoying bug
00:55:19_bilgusnow the issue is that it doesn't save position on USB plug which should be possible ..
01:00:58DEBUGEOF from server (Connection reset by peer) (snapshot: netstuff.c line 545)
01:00:58***Saving seen data "./dancer.seen"
01:00:58***Started Dancer V4.16
01:00:58***Connected to on port 6667
01:00:58***Logfile for #rockbox started
01:00:59Mode"rb-logbot :+i" by rb-logbot
01:01:11***Server message 501: 'rb-logbot :Unknown MODE flag'
01:01:23 Join rb-logbot [0] (
01:01:24 Join akaWolf [0] (
01:01:24 Join edhelas [0] (
01:01:24 Join chorn [0] (
01:01:24 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
01:01:24 Join kadoban [0] (~kadoban@user/kadoban)
01:01:24 Join spork [0] (
01:01:24 Join emacsoma1 [0] (~emacsoman@
01:01:24 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
01:01:24 Join toruvinn [0] (
01:01:24 Join CasBot [0] (
01:01:24 Join Romster [0] (~romster@user/romster)
01:01:24 Join danwellby [0] (~danwellby@
01:01:24 Join JanC [0] (~janc@user/janc)
01:01:24 Join ufdm [0] (
01:01:24 Join TorC [0] (~Tor@fsf/member/TorC)
01:01:24 Join _bilgus [0] (~bilgus@
01:01:24 Join Maxdamantus [0] (~Maxdamant@user/maxdamantus)
01:01:24 Join pablocastellanos [0] (~pidgin@user/pablocastellanos)
01:01:24 Join ddevault [0] (znc@sourcehut/staff/ddevault)
01:01:24 Join reductum [0] (
01:01:24 Join Piece_Maker [0] (
01:01:24 Join wisperwind [0] (~quassel@user/wisperwind)
01:01:24 Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g)
01:01:24 Join benjaoming [0] (~benjaomin@
01:01:24 Join jbgg [0] (~jbgg@
01:01:24 Join pixelma [0] (
01:01:24 Join amiconn [0] (
01:01:24 Join skipwich [0] (~skipwich@user/skipwich)
01:01:24 Join +speachy [0] (~speachy@rockbox/developer/speachy)
01:01:24 Join rando25892 [0] (~sthk@user/rando25892)
01:01:24 Join Natch [0] (
01:01:24 Join dys [0] (~dys@user/dys)
01:01:24 Join f1refly [0] (
01:01:24 Join markun [0] (
01:01:24 Join gevaerts [0] (~fg@user/gevaerts)
01:01:24 Join __builtin [0] (~quassel@rockbox/developer/builtin)
01:01:24 Join Topy44 [0] (
01:01:24 Join wolfshappen_ [0] (
01:01:24 Join tchan [0] (
01:01:24 Join scorche` [0] (
01:01:24 Join user890104 [0] (~Venci@freemyipod/user890104)
01:01:24 Join braewoods [0] (~braewoods@user/braewoods)
01:01:24 Join tomato [0] (~tomato@user/tomato)
01:01:24 Join yang-idle [0] (~yang@user/yang)
01:01:24 Join Riviera [0] (Riviera@user/riviera)
01:01:24 Join yang [0] (~yang@user/yang)
01:01:24 Join Galois [0] (
01:01:24 Join rogeliodh [0] (
01:01:24 Join GeekShad1w [0] (
01:01:24 Join Retr0id [0] (~Retr0id@user/retr0id)
01:01:24 Join rudi_s [0] (~simon@user/rudi-s/x-7673890)
01:01:24 Join bluebrother [0] (
01:01:24 Join SammysHP [0] (
01:01:24 Join ats [0] (
01:01:24 Join yosafbridge [0] (
01:01:24 Join Xeha [0] (
01:01:24 Join vup [0] (~~~~@
01:01:24 Join rasher [0] (~rasher@user/rasher)
01:01:24 Join michaelni [0] (
01:01:24 Join rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility)
01:01:24 Join Guest9931 [0] (
01:01:24 Join XDjackieXD [0] (
01:01:24 Join gsora [0] (~gsora@
01:01:24 Join olspookishmagus [0] (
01:01:24 Join bertrik [0] (~bertrik@revspace/participant/bertrik)
01:01:24 Join funman [0] (
01:01:24 Join ParkerR [0] (
01:01:24 Join kirvesAxe [0] (kirvesaxe@user/kirvesaxe)
01:01:24 Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567)
01:01:24 Join Rondom [0] (~rondom@user/rondom)
01:01:24 Join hook54321 [0] (sid149355@user/hook54321)
01:01:24 Join Arsen [0] (~arsen@managarm/dev/Arsen)
01:19:25rb-bluebotBuild Server message: Build round completed after 781 seconds.
01:19:28rb-bluebotBuild Server message: Revision ee05b8574a result: All green
01:32:08 Join ZincAlloy [0] (
01:36:16 Quit ZincAlloy (Ping timeout: 250 seconds)
01:59:39 Join munkis [0] (
02:08:36 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:81bf:af08:23d8:69c7)
02:13:14 Quit ZincAlloy (Ping timeout: 252 seconds)
03:01:00***Saving seen data "./dancer.seen"
05:01:04***No seen item changed, no save performed.
06:34:15 Quit chorn (Quit: leaving)
07:01:08***Saving seen data "./dancer.seen"
07:41:45 Quit _bilgus (Remote host closed the connection)
07:41:49 Join massiveH [0] (
07:54:17 Join _bilgus [0] (~bilgus@
08:18:20speachy_bilgus: I suspect g#3628 is responsible for a lot of user-experienced issues.
08:18:22rb-bluebotGerrit review #3628 at : tagcache.c Fix potential buffer overruns by William Wilgus
08:18:40speachywell, the underlying bugs, that is
08:20:46_bilgusThere are a few in there but I need to look really close at the way it brings in tag_length and instead of doing those flying checks ensure they are < bufsz
08:21:23_bilguswhich I think might be the case but I ran out of gas first
08:23:57_bilgus <- probably supposed to be static wonder if we can share it with the others
08:24:27_bilgusor. probably covering up something bad
08:25:28_bilgushey the bug I was excited about g#3627 no more playlist control error on USB unplug AFAICT
08:25:29speachywhat's MAX_TAGLEN?
08:25:30rb-bluebotGerrit review #3627 at : playlist.c fix multitude of sins Invalid Control file on USB unplug? by William Wilgus
08:25:57speachymy gut feeling is that it's STATIC to avoid it going on the stack
08:26:15_bilgusthe rest of the functions put it on the stack
08:26:30_bilguswhich is why I was wondering if we could just share buffers
08:27:09_bilgusI think its larger than MAX_PATH
08:28:18_bilguswait AG_MAXLEN pr MAX_TAGLEN?
08:29:02_bilgus#define TAG_MAXLEN (MAX_PATH*2)
08:29:13speachyMAX_PATH is 256 I think?
08:29:24_bilgusI was thinking 384
08:30:11_bilgusso around half a kb
08:30:22speachyget_next() is only called by tagcache_get_next() wich is an external API call
08:30:31_bilgusthats a lot to be putting on the stack too
08:30:36speachybut adding 520 bytes to random callers...
08:31:07speachyhuh, only used by plugins
08:31:12speachyspecifically only by the pictureflow
08:31:21speachywait, tagtree too
08:32:22speachyand the buffer is referenced by the cacheentry struct returned by get_next()
08:32:27speachyso it needs to not be on the stack
08:32:47_bilgusyeah I figured it was the reason
08:32:52speachytagcache.c L1651
08:33:21bertrikI personally start to worry a bit when a module I wrote is more than 1000 lines
08:33:24speachyL1544 too
08:34:02speachy_bilgus: you should add a comment to static char buf[] pointing out why it's static.
08:34:17speachythough tbh I'm not a fan of static arrays declared in a function vs making them true globals.
08:35:22_bilgusIf the data needs to persist though I either need to figure out lifetime or guard it as such
08:36:02speachythe other tagcache buf[]s are more ephemreal and probably can't be shared with that one.
08:36:10_bilgusI'd rather make it global and accessible by the rest with maybe a buflib pull in narrow circumstances
08:37:13_bilgusthat is my thoughts as well
08:37:26_bilgusotherwise it'd probably already be so
08:38:55_bilgusthe next thing will be that now the playlist stays intact through USB plug/unplug it is NOT storing the current index of the playlist
08:39:07_bilgus(other patch)
08:39:39_bilgusthere should be code that holds up the USB ACK till everyone states they are ready
08:40:57_bilgusI think there is already flushing code and even code to save the current playing index and file position (like qwhen you turn off the device)
08:41:18speachy_bilgus: doing that properly will require further restructuring of the USB code, IIRC
08:41:40speachyand would also make that crude menu-on-USB-insertion hack I did work a _lot_ more reliably.
08:41:42_bilguslikely the invalid control file error covered up the breaking of that
08:44:12_bilgusthe menu insertion needs some investigation
08:44:22_bilgusmenu on insertion
08:44:35speachymainly it's being done in the wrong context.
08:45:26speachybecuase we generate the actual USB_INSERTED event _after_ that decision point
08:46:52speachyinstead the event should get triggered immediately, which can then generate the prompt (or not, depending on config), and then ACK the stack to proceed with an orderly shutdown
08:47:20 Quit massiveH (Quit: Leaving)
08:47:39speachyIIRC this is due to the first couple of players (archos, iriver) having separate UMS chips
08:48:17speachyforcing us to kill the world IMMEDIATELY.
08:48:32speachy(and not using USB for charging)
08:48:47speachyyay for historical baggage
08:59:36_bilgusthat makes sense but I did think the whole ACK behavior was already a feature isn't that why we have to answer the USB_INSERT event?
09:00:12speachy...maybe? :)
09:01:08speachythe code effectively ACKs immediately if there are no immediate reasons not to (ie holding down SELECT or whatever)
09:01:10***Saving seen data "./dancer.seen"
09:02:13_bilgusmaybe some finesse will get us there but probably just a dark rabbit hole
09:02:21speachythat it is.
09:03:00speachyI recall going down deep enough to realize that fixing it owuld mean changing the API a bit
09:03:27speachywhich meant touching a lot of code
09:09:53speachyok, in usb_thread() instead of determining what to do upon USB_INSERTED we'd need to kick off an event to the UI, which should post a responsive event to the usb thread, which can then proceed.
09:10:00speachy(or not)
09:12:22speachywhere this gets messy is that some of our targets don't tell us of a USB insertion until we get a request from the host
09:12:53speachythis includes the sansas..
09:15:17speachyso making changes without causing regressions is going to suuuuuck
09:18:46speachyso those DETECT_BY_REQUEST targets completely bypass the SELECT-on-insert or menu prompt
09:23:24 Join tomato2 [0] (~tomato@user/tomato)
09:23:32speachyalas, purging archos wasn't enough to simplify this mess
09:25:30 Join gevaerts_ [0] (~fg@user/gevaerts)
09:34:08 Quit gevaerts (*.net *.split)
09:34:08 Quit tomato (*.net *.split)
09:34:09 Nick tomato2 is now known as tomato (~tomato@user/tomato)
10:16:26 Join bilgus_ph [0] (~bilgus_ph@
10:17:59bilgus_phUSB was one of those long sticky points on the sansas too
10:19:32 Quit bilgus_ph (Client Quit)
11:01:11***Saving seen data "./dancer.seen"
11:58:47 Quit akaWolf (Ping timeout: 265 seconds)
12:02:11 Join akaWolf [0] (
12:15:34 Join ZincAlloy [0] (
12:56:56 Quit edhelas (Remote host closed the connection)
13:01:14***Saving seen data "./dancer.seen"
14:11:51 Nick gevaerts_ is now known as gevaerts (~fg@user/gevaerts)
15:01:18***No seen item changed, no save performed.
15:15:08_bilgus3628 tagcache.c should be pretty safe, I'll try some optimizing this Weekend
17:01:20***No seen item changed, no save performed.
17:35:31braewoods_bilgus: great. i'm still working on inflate.
17:36:08braewoodsi'm now optimizing my work, seeing as i realized how slow bit operations can be so the more i can eliminate redundant checks the better it should perform
17:37:03braewoodszip wasn't super performance critical but decompression needs to be tightly integrated to achieve good performance
18:03:40braewoodsmostly optimizing my IO routines since that's where most of my code was spending its time
18:20:15braewoods_bilgus: should I give adler32 its own source file or so? it's used for ZLIB streams only. I don't know of anything else that even requires it.
18:53:42 Quit ZincAlloy (Quit: Leaving.)
19:01:22***Saving seen data "./dancer.seen"
19:13:44braewoods g#3629
19:13:46rb-bluebotGerrit review #3629 at : adler32: import adapted implementation from tinf/zlib by James Buren
19:17:04 Quit akaWolf (Ping timeout: 250 seconds)
19:33:05 Join dconrad [0] (~dconrad@
20:18:23_bilgusbraewoods, looks like the right way to me..
20:30:02 Join massiveH [0] (
20:32:29braewoods_bilgus: i know it works, should compile with no errors/warnings...
20:33:17rb-bluebotBuild Server message: New build round started. Revision f32fc84ef6, 303 builds, 9 clients.
20:33:36_bilgusthere ya go
20:40:55_bilgusbraewoods, do you think you should include that copyright notice in adler.h as well (zlib.h)
20:44:40rb-bluebotBuild Server message: Build round completed after 684 seconds.
20:44:43rb-bluebotBuild Server message: Revision f32fc84ef6 result: All green
20:48:07braewoods_bilgus: i can add it in a bit.
20:52:52braewoods_bilgus: g#3630
20:52:55rb-bluebotGerrit review #3630 at : adler32: add copyright notice to header as well by James Buren
20:59:30_bilgusor am I reading that wrong?
21:01:24***Saving seen data "./dancer.seen"
21:18:21braewoods_bilgus: huh. it was OK for the modified crc32 i took i thought...
21:19:36braewoodsi guess i didn't understand what you were asking for
21:20:01_bilgusI think I'd ensure that was somewhere with it but IANAL just want to COA
21:21:18braewoodsthe tinf adaptation elsewhere in rockbox...
21:21:23braewoodshas it in the source file
21:21:25braewoodsok then
21:21:34braewoodsi'll fix that up, moment.
21:22:32_bilgusif somnething already has it then just point them to it.. even better
21:24:05braewoods_bilgus: i'm planning to switch that over to the firmware inflate once it's done via the plugin API or so
21:24:17braewoodsso it's probably going to be removed, the inflate bits anyway
21:24:47braewoodsit's used for png support of imageviewer
21:25:44braewoodsi haven't finished but i'm deriving the inflate engine from plan9
21:25:56braewoodsthe rest i'm taking from tinf
21:26:40braewoodsplan9's engine was already designed with a streaming approach in min
21:26:45braewoodsfar easier to adapt
21:27:06braewoodsand pretty good performance for its size
21:27:48braewoodsi'm currently working on an implementation that is better optimized since i realized how much the function call overhead was causing problems
21:27:50 Join seaofducks[m] [0] (~seaofduck@2001:470:69fc:105::cc8d)
21:28:50 Part seaofducks[m]
21:29:25braewoods_bilgus: there, check it again.
21:30:55braewoodsthere. i forgot to include the changes.
21:36:15braewoodsthat completes most of the new inflate engine... just missing the hardest part now...
21:36:26braewoodsthe actual decompression logic :D
21:41:06dconradif somebody wants to take a look at g#3623 I think it's more-or-less good to go, I just have a couple small questions posted on there... It seems to work well though
21:41:08rb-bluebotGerrit review #3623 at : Eros Q Native: Alternate 16-bit volume scaling by Dana Conrad
21:46:59 Join akaWolf [0] (
22:33:20 Join Moriar [0] (
22:49:07rb-bluebotBuild Server message: New build round started. Revision fad4c75163, 303 builds, 9 clients.
23:01:27***Saving seen data "./dancer.seen"
23:01:30rb-bluebotBuild Server message: Build round completed after 743 seconds.
23:01:32rb-bluebotBuild Server message: Revision fad4c75163 result: All green
23:31:19 Quit dconrad (Remote host closed the connection)

Previous day | Next day