00:03:59 | braewoods | so 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:45 | braewoods | _bilgus_: that was weird |
08:02:00 | braewoods | i came back to my fuze+ giving OOM during storage mode |
08:02:22 | braewoods | i wonder if the rebooting of my server with it still connected triggered that |
08:06:10 | braewoods | if so that would suggest a memory leak |
08:06:16 | braewoods | hm |
08:13:10 | braewoods | ah, i see a possible case where it can occur |
08:18:39 | | Quit WakiMiko (Ping timeout: 258 seconds) |
08:19:34 | braewoods | ok, that might be it |
08:20:32 | | Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) |
08:27:42 | braewoods | ... |
08:27:58 | braewoods | speachy: do core_alloc handles ever return 0? |
08:28:03 | braewoods | 0 is a valid index |
08:28:19 | braewoods | i was wondering if it was failing to deallocate it if it was 0 |
08:29:08 | braewoods | really strange |
08:29:30 | braewoods | somehow UMS failed to allocate its buffer during init_connection |
08:47:38 | braewoods | i wonder if we got a buflib bug |
08:47:45 | braewoods | of some kind |
08:47:59 | braewoods | an idling player should not fail to allocate the UMS io buffers |
08:48:55 | braewoods | i'll see if i can trace it but it's probably a leak |
08:49:05 | braewoods | just need to find out what's leaking memory |
08:49:06 | | Quit massiveH (Quit: Leaving) |
08:49:33 | braewoods | or maybe the deallocation is just never performed in some situations |
08:49:38 | * | braewoods ponders |
08:49:58 | braewoods | first to attempt a reproduction |
08:51:09 | braewoods | i'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:41 | braewoods | well i found a leak but not where i expected |
10:02:48 | braewoods | who 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:05 | gevaerts | JdGordon :) |
10:05:14 | braewoods | hm... guess i was wrong just saw this one thing twice |
10:19:33 | | Quit koniu (Ping timeout: 240 seconds) |
10:21:17 | braewoods | only thing i can think of is somehow the buffer doesn't get deallocated |
10:22:01 | braewoods | the 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:09 | braewoods | which could trigger issues in the usb core |
10:22:29 | braewoods | i'll see what happens |
10:22:58 | braewoods | if so maybe we need to be careful about dynamic allocations in the usb core |
10:23:00 | braewoods | o.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:13 | amachronic | speachy: I'd like to set up a TODO list for the M3K so we can coordinate better |
11:55:25 | amachronic | I thought the wiki would be a good place (since everyone can edit), but it seems registration is disabled. |
11:56:00 | braewoods | amachronic: speachy will have to add you |
11:57:01 | amachronic | oh, OK |
11:59:08 | speachy | yeah, spammers gonna spam, and all that. several hundred registration attempts per day still. |
11:59:25 | speachy | amachronic: your name and email used in your gerrit contributions okay? |
12:00 |
12:00:10 | *** | Saving seen data "./dancer.seen" |
12:01:16 | amachronic | yep |
12:35:35 | braewoods | speachy: 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:50 | braewoods | i suspect it could be as simple as denying access for intensive operations |
12:36:07 | braewoods | playback mode probably only needs metadata access |
12:39:08 | braewoods | in any case |
12:39:14 | braewoods | a problem for the future |
12:39:56 | braewoods | but i'll probably try to make it impossible to modify file state in this mode and deny access to object binary data |
12:40:17 | braewoods | speachy: what's the lowest end device for MTP support? |
12:40:20 | braewoods | most PP units? |
12:40:41 | braewoods | it would be a good test of how much it can juggle with MTP and playback |
12:50:03 | speachy | braewoods: keep it simple. we don't have to implement every possilble mtp feature. |
12:50:10 | speachy | and certianly not all at once |
12:51:35 | speachy | File 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:16 | speachy | taking a step back here, who will actually use remote mtp control? What existing clients are out there? |
12:54:31 | speachy | and why use that client to control tethered rockbox instead of a player native to that platform? |
12:57:07 | speachy | rockbox 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:34 | speachy | similarly, 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:17 | speachy | refactoring these things is certianly possible, but it's _work_. |
13:02:11 | speachy | and not something that should hold up initial mtp file transfer functionality. |
13:02:53 | speachy | (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:22 | speachy | amachronic: 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:34 | speachy | amachronic: you should have an email asking you to change your wiki password now. |
13:21:05 | amachronic | speachy: Thanks, wiki seems to be working. I'll update the FAT code later today or tomorrow. |
13:27:09 | speachy | excellent! |
13:27:32 | braewoods | speachy: i would like to implement most of the relevant parts |
13:27:37 | braewoods | speachy: but it can wait |
13:27:42 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
13:27:50 | braewoods | there's only a few trivial properties i could implement without much fuss |
13:28:00 | braewoods | playback and such isn't one of them |
13:28:16 | speachy | braewoods: it's a good goal to have! But incrementally is the way to get there. |
13:28:39 | braewoods | speachy: i plan to add some of the easy ones during this phase |
13:28:42 | | Quit ac_laptop (Ping timeout: 265 seconds) |
13:28:43 | braewoods | mostly to help me test MTP |
13:28:51 | braewoods | e.g., device DateTime property |
13:28:53 | speachy | but to my point about MTP clients, what is out there that implements media control? |
13:29:00 | braewoods | speachy: no idea |
13:29:01 | speachy | (or even datetime?) |
13:29:03 | braewoods | i'd have to look |
13:29:17 | speachy | If you have to end up writing a client to drive that feature, it does diminsh its general usefulness. |
13:29:29 | braewoods | indeed |
13:29:38 | braewoods | the main use of DateTime would be to allow setting the RTC remotely |
13:29:46 | braewoods | which is useful to a point |
13:29:57 | speachy | I mean, right now the biggest bang-for-buck we could do is get bluetooth going on these hibyos-based targets |
13:30:13 | braewoods | isn't the biggest issue have a BT stack? |
13:30:19 | speachy | (but damn, what a %@%@# PITA...) |
13:30:22 | amachronic | I was going to ask about that |
13:30:59 | braewoods | still no progress on YH-925 |
13:31:04 | braewoods | i'll have to dig into it more |
13:31:16 | speachy | bilgus 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:46 | braewoods | speachy: the hotswap feature, what can trigger it? |
13:31:49 | braewoods | just SD card ejection? |
13:32:14 | braewoods | most other storage is considered non-removeable |
13:32:22 | speachy | braewoods: without plugging it in? Yeah, just ejecting storage. |
13:32:41 | braewoods | i'll need to implement that for MTP |
13:32:43 | braewoods | later on |
13:33:17 | speachy | amachronic: 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:39 | amachronic | there's actually a LIBRARY for that? |
13:34:10 | braewoods | speachy: what about arduino? any bluetooth stuff we can use from that? |
13:34:23 | speachy | most of the commercial stacks have been withdrawn from sale. |
13:34:45 | speachy | braewoods: No "classic" stack to be had. |
13:34:55 | braewoods | i see |
13:35:13 | speachy | If we cared about BTLE, there are a _lot_ of options, including one I actually worked on in my last gig. |
13:35:28 | braewoods | what's wrong with BTLE? |
13:35:51 | amachronic | afaik it's not capable of audio or anything like that, correct? |
13:36:54 | braewoods | speachy: in any case i'll focus on the main use case |
13:36:56 | speachy | amachronic: it's a completely different PHY and OTA protocol. Bluetooth only in name. :) |
13:37:33 | braewoods | i will probably add a few trivial extras like DateTime and BatteryLevel |
13:37:34 | speachy | but there is a new audio-over-BTLE spec. |
13:37:57 | braewoods | they don't require storage access to work |
13:38:04 | braewoods | so small addons |
13:38:29 | amachronic | I 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:30 | speachy | but 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:00 | braewoods | there's no plans for regular wifi |
13:39:06 | braewoods | rockbox lacks a network stack |
13:39:19 | braewoods | TCP/IP more accurately |
13:39:27 | speachy | amachronic: our best bet at the moment is probably going to involve porting the linux bluez (or android bluedroid) stacks. |
13:39:55 | amachronic | you mean running on Linux? or porting BlueZ into Rockbox kernel? |
13:40:13 | speachy | amachronic: the latter. |
13:41:00 | braewoods | speachy: did you investigate apache nimble? |
13:41:00 | speachy | the existing x1000 linux platforms already have bluez 4. Except the m3k. |
13:41:13 | amachronic | it 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:28 | speachy | braewoods: the name 'nimBLE' says it all. |
13:41:58 | speachy | amachronic: yet you chose to do a native x1000 port for the m3k. :) |
13:42:36 | amachronic | ha, a bit silly in retrospect, but the prospect of getting Linux working was too daunting |
13:43:40 | amachronic | not planning on doing any other Rockbox ports soon, but it's something for the future |
13:43:43 | speachy | the 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:07 | amachronic | I agree, shanling seemed to do a much better job. |
13:44:07 | speachy | a shame, because some of the quirks I ran into could be trivially fixed if I had the sources. |
13:44:26 | speachy | c'est la vie |
13:45:00 | amachronic | is there any plans to update the rockbox UI? for touchscreens etc. |
13:45:35 | speachy | I think the "plan" is "patches welcome" |
13:46:11 | braewoods | speachy: oh |
13:47:51 | speachy | (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:55 | amachronic | I 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:27 | speachy | there's no ability to handle multitouch or gestures. |
13:52:09 | amachronic | maybe 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:44 | DenimDev | Hi 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:31 | DenimDev | Also the link to the simulator is broken (http://rasher.dk/rockbox/simulator/get.php?file=sandisk-e200-sim-w32.zip) |
14:19:57 | speachy | DenimDev: 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:46 | DenimDev | Thanks speachy, just thought I'd mention it |
14:21:21 | speachy | but 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:57 | speachy | so it shouldn't matter. |
14:24:32 | DenimDev | Thanks, 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:03 | speachy | mi4, I think. |
14:40:09 | DenimDev | Where would I find that? |
14:46:57 | DenimDev | Also 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:41 | DenimDev | It 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) |