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-03-26

00:03:59braewoodsso PP is seriously bugged?
00:28:22_bilgus_well running the lcd init prior to cache init fixes it as well
00:28:43_bilgus_so how do I ensure my data is in the cache in this situation?
00:31:22_bilgus_spoke too soon it locked up on one of the boots after
01:00
01:28:52 Quit koniu (Remote host closed the connection)
01:29:19 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
01:49:22 Join Stanley|00 [0] (~stanley00@unaffiliated/stanley00)
01:49:56 Quit Stanley00 (Ping timeout: 246 seconds)
01:59:58***Saving seen data "./dancer.seen"
02:00
02:17:51 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
02:20:31 Quit Saijin_Naib (Read error: Connection reset by peer)
02:20:53 Quit ZincAlloy (Client Quit)
02:35:03 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-7df3-2d74-9ac4-4c1f.res6.spectrum.com)
03:00
03:24:59 Quit pixelma (Quit: .)
03:25:00 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
03:27:29 Join pixelma [0] (marianne@rockbox/staff/pixelma)
03:27:29 Join amiconn [0] (jens@rockbox/developer/amiconn)
03:59:59***Saving seen data "./dancer.seen"
05:00
05:44:11 Quit koniu (Remote host closed the connection)
06:00
06:00:02***Saving seen data "./dancer.seen"
06:00:41 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
06:15:42 Quit Stanley|00 ()
07:00
07:37:41 Quit braewoods (Quit: WeeChat 2.8)
07:42:16 Join braewoods [0] (~braewoods@learnprogramming/staff/braewoods)
07:49:54 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
07:57:20 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
08:00
08:00:05***Saving seen data "./dancer.seen"
08:01:45braewoods_bilgus_: that was weird
08:02:00braewoodsi came back to my fuze+ giving OOM during storage mode
08:02:22braewoodsi wonder if the rebooting of my server with it still connected triggered that
08:06:10braewoodsif so that would suggest a memory leak
08:06:16braewoodshm
08:13:10braewoodsah, i see a possible case where it can occur
08:18:39 Quit WakiMiko (Ping timeout: 258 seconds)
08:19:34braewoodsok, that might be it
08:20:32 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
08:27:42braewoods...
08:27:58braewoodsspeachy: do core_alloc handles ever return 0?
08:28:03braewoods0 is a valid index
08:28:19braewoodsi was wondering if it was failing to deallocate it if it was 0
08:29:08braewoodsreally strange
08:29:30braewoodssomehow UMS failed to allocate its buffer during init_connection
08:47:38braewoodsi wonder if we got a buflib bug
08:47:45braewoodsof some kind
08:47:59braewoodsan idling player should not fail to allocate the UMS io buffers
08:48:55braewoodsi'll see if i can trace it but it's probably a leak
08:49:05braewoodsjust need to find out what's leaking memory
08:49:06 Quit massiveH (Quit: Leaving)
08:49:33braewoodsor maybe the deallocation is just never performed in some situations
08:49:38*braewoods ponders
08:49:58braewoodsfirst to attempt a reproduction
08:51:09braewoodsi'll look at it later
09:00
09:23:38 Quit ac_laptop (Ping timeout: 240 seconds)
10:00
10:00:06***Saving seen data "./dancer.seen"
10:01:41braewoodswell i found a leak but not where i expected
10:02:48braewoodswho here knows the theme engine?
10:02:51 Quit koniu (Remote host closed the connection)
10:03:24 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
10:04:05gevaertsJdGordon :)
10:05:14braewoodshm... guess i was wrong just saw this one thing twice
10:19:33 Quit koniu (Ping timeout: 240 seconds)
10:21:17braewoodsonly thing i can think of is somehow the buffer doesn't get deallocated
10:22:01braewoodsthe host i had it connected to tends to get flaky on the host side after a long run time
10:22:06 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
10:22:09braewoodswhich could trigger issues in the usb core
10:22:29braewoodsi'll see what happens
10:22:58braewoodsif so maybe we need to be careful about dynamic allocations in the usb core
10:23:00braewoodso.O
10:23:14 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
11:00
11:06:46 Quit Saijin_Naib (Remote host closed the connection)
11:07:02 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-7df3-2d74-9ac4-4c1f.res6.spectrum.com)
11:33:23 Quit RafiX (Ping timeout: 258 seconds)
11:47:09 Join RafiX [0] (rafix@junkcc.net)
11:52:54 Join amachronic [0] (5284b8e8@82.132.184.232)
11:55:13amachronicspeachy: I'd like to set up a TODO list for the M3K so we can coordinate better
11:55:25amachronicI thought the wiki would be a good place (since everyone can edit), but it seems registration is disabled.
11:56:00braewoodsamachronic: speachy will have to add you
11:57:01amachronicoh, OK
11:59:08speachyyeah, spammers gonna spam, and all that. several hundred registration attempts per day still.
11:59:25speachyamachronic: your name and email used in your gerrit contributions okay?
12:00
12:00:10***Saving seen data "./dancer.seen"
12:01:16amachronicyep
12:35:35braewoodsspeachy: interesting. seems mtp playback control requires storage access so i will need to find a way to make exclusive access and playback mode co-exist to a degree
12:35:50braewoodsi suspect it could be as simple as denying access for intensive operations
12:36:07braewoodsplayback mode probably only needs metadata access
12:39:08braewoodsin any case
12:39:14braewoodsa problem for the future
12:39:56braewoodsbut i'll probably try to make it impossible to modify file state in this mode and deny access to object binary data
12:40:17braewoodsspeachy: what's the lowest end device for MTP support?
12:40:20braewoodsmost PP units?
12:40:41braewoodsit would be a good test of how much it can juggle with MTP and playback
12:50:03speachybraewoods: keep it simple. we don't have to implement every possilble mtp feature.
12:50:10speachyand certianly not all at once
12:51:35speachyFile transfer is the only feature that ultimately matters. and that can be done in an exclusive mode. once that is stable (which is in of itself a _ton_ of work) additional functionality (and the restructuring necessary) can be layered on.
12:53:16speachytaking a step back here, who will actually use remote mtp control? What existing clients are out there?
12:54:31speachyand why use that client to control tethered rockbox instead of a player native to that platform?
12:57:07speachyrockbox is not built around the notion that multiple things can be accessing the disk at once. there are no mechanims in place to ensure exclusive file access, or notify upon changes.
13:00
13:00:34speachysimilarly, the usb code is set up assuming it runs exclusively, ie not sharing resources with other things like plugins, playback/codecs, keypad/input, and so forth.
13:01:17speachyrefactoring these things is certianly possible, but it's _work_.
13:02:11speachyand not something that should hold up initial mtp file transfer functionality.
13:02:53speachy(refactoring that stuff is a major undertaking in of itself, with the potential of causing a ton of regressions)
13:06:26 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
13:11:22speachyamachronic: let's rename the #define and land the FAT realignment code. We can blanket-enable it on the x1000 and jz47xx ports, and work out a way to better integrate the others that implement their own realignment buffers.
13:15:34speachyamachronic: you should have an email asking you to change your wiki password now.
13:21:05amachronicspeachy: Thanks, wiki seems to be working. I'll update the FAT code later today or tomorrow.
13:27:09speachyexcellent!
13:27:32braewoodsspeachy: i would like to implement most of the relevant parts
13:27:37braewoodsspeachy: but it can wait
13:27:42 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
13:27:50braewoodsthere's only a few trivial properties i could implement without much fuss
13:28:00braewoodsplayback and such isn't one of them
13:28:16speachybraewoods: it's a good goal to have! But incrementally is the way to get there.
13:28:39braewoodsspeachy: i plan to add some of the easy ones during this phase
13:28:42 Quit ac_laptop (Ping timeout: 265 seconds)
13:28:43braewoodsmostly to help me test MTP
13:28:51braewoodse.g., device DateTime property
13:28:53speachybut to my point about MTP clients, what is out there that implements media control?
13:29:00braewoodsspeachy: no idea
13:29:01speachy(or even datetime?)
13:29:03braewoodsi'd have to look
13:29:17speachyIf you have to end up writing a client to drive that feature, it does diminsh its general usefulness.
13:29:29braewoodsindeed
13:29:38braewoodsthe main use of DateTime would be to allow setting the RTC remotely
13:29:46braewoodswhich is useful to a point
13:29:57speachyI mean, right now the biggest bang-for-buck we could do is get bluetooth going on these hibyos-based targets
13:30:13braewoodsisn't the biggest issue have a BT stack?
13:30:19speachy(but damn, what a %@%@# PITA...)
13:30:22amachronicI was going to ask about that
13:30:59braewoodsstill no progress on YH-925
13:31:04braewoodsi'll have to dig into it more
13:31:16speachybilgus has a protoype UI of sorts, the toolchain now has all of the necessary libs/etc to hook into the system bt stack; but now the middle later needs to be written.
13:31:46braewoodsspeachy: the hotswap feature, what can trigger it?
13:31:49braewoodsjust SD card ejection?
13:32:14braewoodsmost other storage is considered non-removeable
13:32:22speachybraewoods: without plugging it in? Yeah, just ejecting storage.
13:32:41braewoodsi'll need to implement that for MTP
13:32:43braewoodslater on
13:33:17speachyamachronic: but our options for a _native_ stack are pretty much nonexistent. There is one that is perfect technically, but its licensing is completely incompatible with rockbox.
13:33:39amachronicthere's actually a LIBRARY for that?
13:34:10braewoodsspeachy: what about arduino? any bluetooth stuff we can use from that?
13:34:23speachymost of the commercial stacks have been withdrawn from sale.
13:34:45speachybraewoods: No "classic" stack to be had.
13:34:55braewoodsi see
13:35:13speachyIf we cared about BTLE, there are a _lot_ of options, including one I actually worked on in my last gig.
13:35:28braewoodswhat's wrong with BTLE?
13:35:51amachronicafaik it's not capable of audio or anything like that, correct?
13:36:54braewoodsspeachy: in any case i'll focus on the main use case
13:36:56speachyamachronic: it's a completely different PHY and OTA protocol. Bluetooth only in name. :)
13:37:33braewoodsi will probably add a few trivial extras like DateTime and BatteryLevel
13:37:34speachybut there is a new audio-over-BTLE spec.
13:37:57braewoodsthey don't require storage access to work
13:38:04braewoodsso small addons
13:38:29amachronicI was curious about any plans for bluetooth, since I've got a shanling q1 which is X1000-based and has got a bluetooth+wifi SDIO card
13:38:30speachybut if you want to use rockbox to talk to (eg) your car or the enormous number of BT speakers out there, it's going to be classic bluetooth with the A2DP and AVRCP profiles.
13:39:00braewoodsthere's no plans for regular wifi
13:39:06braewoodsrockbox lacks a network stack
13:39:19braewoodsTCP/IP more accurately
13:39:27speachyamachronic: our best bet at the moment is probably going to involve porting the linux bluez (or android bluedroid) stacks.
13:39:55amachronicyou mean running on Linux? or porting BlueZ into Rockbox kernel?
13:40:13speachyamachronic: the latter.
13:41:00braewoodsspeachy: did you investigate apache nimble?
13:41:00speachythe existing x1000 linux platforms already have bluez 4. Except the m3k.
13:41:13amachronicit turns out that recent 5.x kernels support quite a lot of X1000 features, so porting Linux to the X1000 and building a userspace is also an option for devices that implement Linux poorly. problem would be proprietary drivers though
13:41:28speachybraewoods: the name 'nimBLE' says it all.
13:41:58speachyamachronic: yet you chose to do a native x1000 port for the m3k. :)
13:42:36amachronicha, a bit silly in retrospect, but the prospect of getting Linux working was too daunting
13:43:40amachronicnot planning on doing any other Rockbox ports soon, but it's something for the future
13:43:43speachythe m3k's native linux platform was such a clusterf* that a total replacement made more sense than trying to fix it −− and fiio even provided source code. the others are much, much better put together, but... no source code.
13:44:07amachronicI agree, shanling seemed to do a much better job.
13:44:07speachya shame, because some of the quirks I ran into could be trivially fixed if I had the sources.
13:44:26speachyc'est la vie
13:45:00amachronicis there any plans to update the rockbox UI? for touchscreens etc.
13:45:35speachyI think the "plan" is "patches welcome"
13:46:11braewoodsspeachy: oh
13:47:51speachy(that's not quite fair; the core does handle touchscreens reasonably well, but a touch-based UI requires a completely different approach to what's been implemented..)
13:47:55amachronicI was thinking of redesigning the input handling, but it's just an idea right now
13:48:26 Quit Saijin_Naib (Read error: Connection reset by peer)
13:48:27speachythere's no ability to handle multitouch or gestures.
13:52:09amachronicmaybe I'll push a draft of the input thing so you can get the idea. it's state machine based, my intention is to support things that are hard to do right now like double-clicking buttons, and user customization of keymaps.
13:55:04 Quit amachronic (Quit: Connection closed)
14:00
14:00:11***Saving seen data "./dancer.seen"
14:05:05 Join DenimDev [0] (~newdeaths@c-71-204-24-131.hsd1.ga.comcast.net)
14:07:55 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:1e:30a2:7e18:c41b)
14:10:44DenimDevHi guys, I read all the documentation I could find on my sansa e200, but I was unable to find if firmware 1.02.15A is supported
14:12:16 Quit ZincAlloy (Ping timeout: 240 seconds)
14:14:50 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:1e:30a2:7e18:c41b)
14:17:31DenimDevAlso the link to the simulator is broken (rasher.dk/rockbox/simulator/get.php?file=sandisk-e200-sim-w32.zip">http://rasher.dk/rockbox/simulator/get.php?file=sandisk-e200-sim-w32.zip)
14:19:57speachyDenimDev: the stuff rasher put up on his web site is quite outdated. FWIW I don't think rockbox ever provided/supported simulator builds.
14:20:46DenimDevThanks speachy, just thought I'd mention it
14:21:21speachybut all I can suggest with respect to that e200 firmware is to try it. IIRC we use generic parsing code to patch the sansa OF images.
14:21:57speachyso it shouldn't matter.
14:24:32DenimDevThanks, I figured it would be compatible, but I'm not a fan of bricks :)
14:36:21 Quit koniu (Ping timeout: 240 seconds)
14:38:53 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-7df3-2d74-9ac4-4c1f.res6.spectrum.com)
14:39:46_bilgus_DenimDev, we check by checksum for supported versions in sansa ams patcher I don't remember what the e200 uses is it ams or mi4?
14:40:03speachymi4, I think.
14:40:09DenimDevWhere would I find that?
14:46:57DenimDevAlso the rockbox auto installer "detected" wine, even though I'm on win10
14:50:40 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
14:55:41DenimDevIt worked
15:00
15:03:07 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
15:31:07 Quit koniu (Remote host closed the connection)
15:48:27 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
16:00
16:00:15***Saving seen data "./dancer.seen"
17:00
17:27:51 Quit Saijin_Naib (Remote host closed the connection)
18:00
18:00:18***Saving seen data "./dancer.seen"
18:46:22 Quit lebellium (Quit: Leaving)
18:50:51 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
18:57:14 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu)
19:00
19:00:45 Quit koniu (Ping timeout: 240 seconds)
19:26:36 Quit ZincAlloy (Quit: Leaving.)
20:00
20:00:21***Saving seen data "./dancer.seen"
20:03:04 Join MrZeus [0] (~MrZeus@194.37.96.151)
20:22:17 Quit pamaury (Ping timeout: 260 seconds)
20:56:46 Quit ac_laptop (Ping timeout: 240 seconds)
20:57:35 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
21:00
21:30:58 Quit MrZeus (Ping timeout: 240 seconds)
22:00
22:00:23***Saving seen data "./dancer.seen"
22:33:36 Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
22:34:05 Quit ufdm (Ping timeout: 252 seconds)
22:34:05 Quit ufdm_ (Read error: Connection reset by peer)
22:53:24 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
23:00
23:12:45 Join f1reflyylmao [0] (~f1refly@2a01:c22:8c52:8400:4862:5b4:bd57:e576)
23:14:46 Quit f1refly (Ping timeout: 240 seconds)
23:14:46 Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c22:8c52:8400:4862:5b4:bd57:e576)
23:32:55 Quit cockroach (Quit: leaving)

Previous day | Next day