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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2021-08-16

00:05:45 Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net)
00:10:22***Saving seen data "./dancer.seen"
00:42:38 Quit Arsen (*.net *.split)
00:42:40 Quit Natch (*.net *.split)
00:42:40 Quit gevaerts (*.net *.split)
00:42:40 Quit michaelni (*.net *.split)
00:42:40 Quit spork (*.net *.split)
00:42:40 Quit TorC (*.net *.split)
00:42:40 Quit ats (*.net *.split)
00:42:40 Quit vup (*.net *.split)
00:43:14 Join Arsen [0] (~arsen@managarm/dev/Arsen)
00:43:14 Join Natch [0] (~natch@c-e070e255.014-297-73746f25.bbcust.telenor.se)
00:43:14 Join gevaerts [0] (~fg@user/gevaerts)
00:43:14 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at)
00:43:14 Join spork [0] (topic@31-151-2-135.dynamic.upc.nl)
00:43:14 Join TorC [0] (~Tor@fsf/member/TorC)
00:43:14 Join ats [0] (~ats@cartman.offog.org)
00:43:14 Join vup [0] (~~~~@46.101.193.235)
00:44:55 Quit braewoods (*.net *.split)
00:44:55 Quit blbro[m] (*.net *.split)
00:44:56 Quit jadzia (*.net *.split)
00:44:56 Quit Piece_Maker (*.net *.split)
00:44:56 Quit ufdm (*.net *.split)
00:44:56 Quit danwellby (*.net *.split)
00:45:23 Join braewoods [0] (~braewoods@user/braewoods)
00:45:23 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
00:45:23 Join jadzia [0] (~jadzia@2604:3d09:1b83:f200::2998)
00:45:23 Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net)
00:45:23 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
00:45:23 Join danwellby [0] (~danwellby@88.97.8.245)
00:46:11 Quit kadoban (Ping timeout: 240 seconds)
00:46:56 Quit blbro[m] (Ping timeout: 256 seconds)
00:47:18 Quit paulcarroty (Ping timeout: 272 seconds)
00:48:03 Quit JanC (*.net *.split)
00:48:04 Quit jackie (*.net *.split)
00:48:04 Quit jschwart (*.net *.split)
00:48:04 Quit kirvesAxe (*.net *.split)
00:48:43 Join JanC [0] (~janc@user/janc)
00:48:43 Join jackie [0] (~jackie@banana-new.kilobyte22.de)
00:48:43 Join kirvesAxe [0] (~kirvesaxe@user/kirvesaxe)
00:48:43 Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567)
00:50:21 Quit benjaoming (*.net *.split)
00:50:21 Quit markun_ (*.net *.split)
00:50:45 Join benjaoming [0] (~benjaomin@37.139.19.237)
00:50:45 Join markun_ [0] (~markun@178-84-100-63.dynamic.upc.nl)
00:54:11 Quit jbgg (*.net *.split)
00:54:11 Quit SammysHP (*.net *.split)
00:54:11 Quit Rondom (*.net *.split)
00:54:15 Join jbgg_ [0] (~jbgg@95.179.159.229)
00:54:31 Join Rondom_ [0] (~rondom@user/rondom)
00:55:35 Join SammysHP [0] (~SammysHP@faol.sammyshp.de)
01:00
01:34:47 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
02:00
02:10:26***Saving seen data "./dancer.seen"
02:27:28 Join paulcarroty [0] (~paulcarro@2001:470:69fc:105::216)
03:00
03:11:14 Join petur [0] (~petur@77.77.179.66)
03:15:27 Join kadoban [0] (~kadoban@user/kadoban)
03:44:57 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:f493:d3e1:6253:901b)
04:00
04:10:30***No seen item changed, no save performed.
04:20:06 Quit braewoods (Quit: WeeChat 2.8)
04:20:30 Join braewoods [0] (~braewoods@user/braewoods)
04:21:29braewoods_bilgus: incidently if they really need to they can use the dostime functions I wrote up to manipulate time. o.O
04:21:43braewoodsor otherwise refactored rather
04:27:55 Quit petur (Quit: Connection reset by beer)
05:00
05:31:18 Join F3l1x_10m [0] (~Al3x_10m@user/f3l1x-10m/x-3393542)
06:00
06:10:33***Saving seen data "./dancer.seen"
06:41:48 Quit Guest9931 (Quit: WeeChat 2.3)
06:42:05 Join leachim6 [0] (~leachim6@user/leachim6)
07:00
07:16:44 Quit Moriar (Ping timeout: 268 seconds)
08:00
08:10:35***Saving seen data "./dancer.seen"
08:15:09 Quit ZincAlloy (Quit: Leaving.)
08:16:22 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de)
08:44:35 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09:00
09:10:52 Join cockroach [0] (~blattodea@user/cockroach)
09:17:29 Join IPG [0] (~IPG@90.199.224.62)
09:24:37_bilgusI couldn't get it to take a search string containing mtime (it won't display bad ones)
09:25:52_bilgusmight be just bad format on my part or its broken
09:54:14 Quit ddevault (Quit: Why do I even put this quit message in if I never quit)
10:00
10:03:34 Join ddevault [0] (znc@sourcehut/staff/ddevault)
10:10:37***Saving seen data "./dancer.seen"
10:16:51 Quit massiveH (Quit: Leaving)
10:32:20 Quit IPG (Read error: Connection reset by peer)
11:00
11:48:37 Join amachronic [0] (~amachroni@user/amachronic)
12:00
12:07:40amachronic_bilgus I saw the patch but I'm not brave enough to revive it :)
12:09:09amachronici figure a simple path based approach will work just as well to redirect the .rockbox directory, although it's not entirely the same
12:10:38***Saving seen data "./dancer.seen"
12:46:52 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:7034:ea26:53fb:7bf9)
12:49:41_bilgusClearly I am brave enough but not smart enough to get it to the finish lol
12:50:38_bilgusI was saying more for the reference than reviving
12:57:42amachronicafaict the only purpose of involving the bootloader in multiboot was to arrange for another drive to be mounted as volume 0
12:58:13amachronicif the .rockbox directory can be any directory then there won't be any need for that
12:58:57amachronicwell, aside from scanning for the right rockbox.bin to load
13:00
13:12:15braewoodsso we're trying to add support for a non-hardcoded rockbox root directory?
13:15:06_bilgusYOU WOULD STILL NEED TO KNOW WHAT DRIVE YOU LOADED FROM
13:15:08_bilgusoops
13:15:41_bilgusfigure the bootloader copies a fw into memory the fw doesn't have any clue where its origin is
13:16:27braewoods_bilgus: same problem for the linux kernel, no? you need to specify root if it's not running totally from ram.
13:16:41amachronictechnically fw can just re-run the same routine as the bootloader to find where its origin is
13:16:52_bilguseven with .rockbox being anywhere the fw still needs to know, now could you scan everywhere for valid fw and decide thats the probable mount point
13:17:18amachronicit does become a problem if the bootloader has a menu to select from multiple installed fw versions
13:21:40_bilguswhich is kinda the eventual idea..
13:22:28braewoodsso the main approach then would be to scan the entire disk for the binary to find possible root directories
13:22:38braewoodswould will be expensive for larger disks
13:22:43braewoodswhich
13:22:46_bilgusthat makes for a not very nice boot time
13:22:58braewoodsyou could limit to directories under the root directory
13:23:07amachronicthe current multiboot code is reading the path from a file so it's not like we'd need to scan the entire disk.
13:23:13speachyhonestly I don't see it as terribly useful in a general sense
13:23:25braewoodsindeed, it's mainly useful for oddities like the Sansas.
13:23:42braewoodsfor most targets with single storage, it's pointless.
13:23:45speachyonly when there's more than physical storage device
13:23:51speachymore than one
13:24:07_bilgusI really like the idea of being able to have 4 different builds co existing on the same card
13:24:09braewoodsi think the only multi storage units are using sd cards anyway
13:24:37speachyfour builds for the same target, or four different targets?
13:25:00_bilgusnot to mention leaving a build on internal for debug
13:25:08_bilgus4 different
13:25:12braewoodsthat doesn't sound particularly useful in either case
13:25:19_bilgusotherwise you need to edit the redirect file
13:25:20braewoodsonly for SD cards at most
13:25:38speachythat poses an interesthing problem for our distributed zip/etc files
13:26:02braewoodswell it would mean we need to change how we name root directories since these targets are incompatible with each other
13:26:20braewoodsone idea?
13:26:31_bilgusI think it should always be a .rockbox directory (like windows)
13:26:33braewoodswe could place it all under .rockbox but add a second layer of directories
13:26:41_bilgusbut it doesn't need to be root
13:26:43braewoodsfor target specific stuff
13:26:50CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
13:26:50*braewoods shrugs.
13:27:18braewoodswe already support renaming the root directory
13:27:18speachywe can't share anything, really. don't know if our on-disk database format is necessarily compatible between targets either.
13:27:25braewoodsindeed.
13:27:33braewoodswe could share a base directory but nothing else.
13:27:43_bilgus'/' bleh/.rockbox
13:27:48braewoodsor
13:27:52braewoods/.rockbox/h120
13:27:54braewoodsetc
13:28:10braewoodsit may be helpful if the base directory is still .rockbox
13:28:17_bilgusthat direction would bring big issues currently
13:28:24amachronicmy current strategy is purely making everything in rbpaths.h based on a dynamic ROCKBOX_DIR instead of hardcoding it to .rockbox
13:28:38amachronicthis is a bit different from the old root redirect patch
13:28:52amachronicthe default would still be /.rockbox though
13:29:03braewoodscould we make that base path into a char array that is const to external access?
13:29:16braewoodsit sounds like it only needs tto be set once per boot.
13:29:19speachywe can't afford to naively walk the filesystem.
13:29:41amachronicyes the path would be effectively const after boot.
13:29:47braewoodsbut that will cause issues for anything using compile time string conconcatenation
13:29:54speachythere would have to be a reasonably-guaranteed location to check for a given target.
13:30:02speachyeg .targetname/.rockbox
13:30:28braewoodsand ideally it would be in a memory region that is never written to except when attempting to boot a new kernel
13:31:12braewoodsit would need to be at least 32 bytes for alignment reasons i believe
13:31:15speachyamachronic: I think your approach is the only sane way to go about things.
13:31:34braewoodsi can't foresee this needing to be super long most of the time
13:31:37speachybut we can't afford to walk the filesystem in the bootloader to find candidates to boot
13:31:44braewoodsthe less memory we waste on it the better
13:31:56speachyie either it's in a target-specific location, or .rockbox
13:32:11amachronicspeachy: I agree walking the filesystem is a bad idea.
13:32:40braewoodsyea, this isn't a linux desktop with tons of resources :
13:32:42braewoods:D
13:32:56amachronicthe current multiboot code we have checks for a file rockbox_main.TARGET and reads the redirect path from there.
13:33:02amachronicof course the redirection part is not actually implemented...
13:33:12speachyamachronic: having ROCKBOX_DIR "dynamic" would make some of the gyrations in the hosted ports unnecessary
13:33:18_bilgusits handled by fw
13:33:37amachronicextending the redirect path to a list would be easy enough. We could even have a plugin in rockbox to scan for candidates and update the list.
13:33:44amachronicso you don't have to edit it by hand
13:34:01amachronicbut having a default 'alternate' location works too
13:34:06speachybut we can't blindly infer ROCKBOX_DIR from the path to the fw binary either.
13:34:49amachronicwell, isn't there pretty much 1-to-1 mapping between the two?
13:35:07speachynot on the hosted side of things. :)
13:35:57amachronicdo you mean the case where there's one read-only path for plugins etc. and a r/w path for plugin data?
13:37:35speachyno, in teh sense that the binary is copied to /tmp before it's launched
13:38:06speachyotherwise it causes problems when trying to redirect the sd card for usb operation
13:38:26amachronicoh. Isn't that an irrelevant detail because the binary still resides in the ROCKBOX_DIR anyway?
13:38:34amachronicas bilgus said the fw has no way to know where it's running from
13:38:58amachronicon hosted we could (but it'd be incorrect), but on native no way
13:39:09speachythe binary starts there, but is copied elsewhere by the startup (and rolo) scripts.
13:39:38braewoodsamachronic: btw, you did the fiio port?
13:39:40speachybut yeah, the "bootloader" handles that copying technically
13:39:53speachyso it's moot for purposes of this conversation I think.
13:39:58amachronicexactly, so we still have a ROCKBOX_DIR which determines the binary to load and how it gets executed is an implementation detail
13:40:15amachronicbraewoods: the native one, not hosted.
13:40:24braewoodsamachronic: if so, any idea how hard the battery is to replace?
13:40:31braewoodsi'm just curious at this point.
13:40:38amachronicnever opened it, so I don't know.
13:40:41braewoodsoh.
13:40:47speachybraewoods: it's a PITA to disassemble
13:40:49amachronicThe screen is glued and you need to dissolve that glue first
13:40:52speachyvery easy to damage
13:40:57amachronicand everything inside is soldered
13:41:00braewoodsspeachy: oh, so basically landfill ready.
13:41:05braewoodsgreat.
13:41:32braewoodsi've started calling products made ridiculiously hard to repair as "landfill ready"
13:42:19amachronicand if you run the OF it will burn out the NAND flash with many megabytes/day of debug logging
13:42:28amachronicbasically its designed to break in 1 or 2 years
13:43:13braewoodsthat's inexcusable. production firmware shouldn't be doing that.
13:43:26amachronicOh yeah, they disabled software ECC too.
13:43:36braewoodsyou mean ECC RAM?
13:43:39amachronicone flipped bit in the wrong place -> instant brick
13:43:45amachronicno, ECC on the NAND flash.
13:43:51braewoodsOh. That's stupid.
13:44:12braewoodsdespite their age I really prefer my older rockbox targets.
13:44:12amachronicin the extreme. Since they had free Linux implementations and performance here is a non-issue.
13:45:28braewoodsmakes me think we need to design our own option at some point.
13:46:31braewoodsspeachy: how's your collection? do you need a gigabeat S to add to it?
13:52:45speachyeh, thanks but I have plenty of other units here for random devel/debug purposes
13:52:54speachydaily driver is an increasingly beat-up xduoo x3
13:53:35braewoodsoh, i see.
13:54:05speachysomething to be said for a player you could drive over without damaging it.
13:55:01sporkipod nano 2g probably can handle that too
13:59:00sporknice that a side-effect of rockbox is that it extends nand life too
14:00
14:10:39***No seen item changed, no save performed.
14:42:12 Join dbohdan [0] (~dbohdan@user/dbohdan)
14:47:32 Quit amachronic (Quit: amachronic)
16:00
16:10:40***Saving seen data "./dancer.seen"
17:00
17:38:24 Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net)
17:52:18 Quit lebellium (Quit: Leaving)
18:00
18:01:36 Join rudi_s_ [0] (~simon@user/rudi-s/x-7673890)
18:02:09 Quit rudi_s (Ping timeout: 248 seconds)
18:10:43***Saving seen data "./dancer.seen"
18:44:17 Quit Ckat (Ping timeout: 252 seconds)
18:46:14 Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g)
19:00
19:28:58 Quit amiconn (Ping timeout: 258 seconds)
19:29:20 Quit pixelma (Ping timeout: 268 seconds)
19:34:08 Join pixelma [0] (marianne@p200300ea8705bb00305e95fffec66ff3.dip0.t-ipconnect.de)
19:36:46 Quit jadzia (Quit: jadzia)
19:38:47 Quit pixelma (Ping timeout: 245 seconds)
19:41:05 Join pixelma [0] (marianne@p200300ea8707db00305e95fffec66ff3.dip0.t-ipconnect.de)
19:41:05 Join amiconn [0] (jens@p200300ea8707db00305e95fffec66ff3.dip0.t-ipconnect.de)
20:00
20:10:44***Saving seen data "./dancer.seen"
20:42:45 Join skipwich [0] (~skipwich@user/skipwich)
20:52:54 Quit ZincAlloy (Quit: Leaving.)
21:00
21:27:07 Quit cockroach (Ping timeout: 245 seconds)
21:30:29 Quit j-r (Ping timeout: 258 seconds)
21:31:08 Join j-r [0] (~j-r@p20030006215aee49404207fffefd0a65.dip0.t-ipconnect.de)
22:00
22:10:45***Saving seen data "./dancer.seen"
23:00
23:02:16 Quit skipwich (Quit: DISCONNECT)
23:02:55 Join skipwich [0] (~skipwich@user/skipwich)

Previous day | Next day