--- Log for 26.03.121 Server: weber.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 10 hours and 4 minutes ago 00.03.59 # 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.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.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.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.44.11 Quit koniu (Remote host closed the connection) 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.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.05 *** Saving seen data "./dancer.seen" 08.01.45 # _bilgus_: that was weird 08.02.00 # i came back to my fuze+ giving OOM during storage mode 08.02.22 # i wonder if the rebooting of my server with it still connected triggered that 08.06.10 # if so that would suggest a memory leak 08.06.16 # hm 08.13.10 # ah, i see a possible case where it can occur 08.18.39 Quit WakiMiko (Ping timeout: 258 seconds) 08.19.34 # ok, that might be it 08.20.32 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 08.27.42 # ... 08.27.58 # speachy: do core_alloc handles ever return 0? 08.28.03 # 0 is a valid index 08.28.19 # i was wondering if it was failing to deallocate it if it was 0 08.29.08 # really strange 08.29.30 # somehow UMS failed to allocate its buffer during init_connection 08.47.38 # i wonder if we got a buflib bug 08.47.45 # of some kind 08.47.59 # an idling player should not fail to allocate the UMS io buffers 08.48.55 # i'll see if i can trace it but it's probably a leak 08.49.05 # just need to find out what's leaking memory 08.49.06 Quit massiveH (Quit: Leaving) 08.49.33 # or maybe the deallocation is just never performed in some situations 08.49.38 # * braewoods ponders 08.49.58 # first to attempt a reproduction 08.51.09 # i'll look at it later 09.23.38 Quit ac_laptop (Ping timeout: 240 seconds) 10.00.06 *** Saving seen data "./dancer.seen" 10.01.41 # well i found a leak but not where i expected 10.02.48 # 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 # JdGordon :) 10.05.14 # hm... guess i was wrong just saw this one thing twice 10.19.33 Quit koniu (Ping timeout: 240 seconds) 10.21.17 # only thing i can think of is somehow the buffer doesn't get deallocated 10.22.01 # 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 # which could trigger issues in the usb core 10.22.29 # i'll see what happens 10.22.58 # if so maybe we need to be careful about dynamic allocations in the usb core 10.23.00 # o.O 10.23.14 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 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 # speachy: I'd like to set up a TODO list for the M3K so we can coordinate better 11.55.25 # I thought the wiki would be a good place (since everyone can edit), but it seems registration is disabled. 11.56.00 # amachronic: speachy will have to add you 11.57.01 # oh, OK 11.59.08 # yeah, spammers gonna spam, and all that. several hundred registration attempts per day still. 11.59.25 # amachronic: your name and email used in your gerrit contributions okay? 12.00.10 *** Saving seen data "./dancer.seen" 12.01.16 # yep 12.35.35 # 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 # i suspect it could be as simple as denying access for intensive operations 12.36.07 # playback mode probably only needs metadata access 12.39.08 # in any case 12.39.14 # a problem for the future 12.39.56 # 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 # speachy: what's the lowest end device for MTP support? 12.40.20 # most PP units? 12.40.41 # it would be a good test of how much it can juggle with MTP and playback 12.50.03 # braewoods: keep it simple. we don't have to implement every possilble mtp feature. 12.50.10 # and certianly not all at once 12.51.35 # 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 # taking a step back here, who will actually use remote mtp control? What existing clients are out there? 12.54.31 # and why use that client to control tethered rockbox instead of a player native to that platform? 12.57.07 # 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.34 # 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 # refactoring these things is certianly possible, but it's _work_. 13.02.11 # and not something that should hold up initial mtp file transfer functionality. 13.02.53 # (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 # 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 # amachronic: you should have an email asking you to change your wiki password now. 13.21.05 # speachy: Thanks, wiki seems to be working. I'll update the FAT code later today or tomorrow. 13.27.09 # excellent! 13.27.32 # speachy: i would like to implement most of the relevant parts 13.27.37 # speachy: but it can wait 13.27.42 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.27.50 # there's only a few trivial properties i could implement without much fuss 13.28.00 # playback and such isn't one of them 13.28.16 # braewoods: it's a good goal to have! But incrementally is the way to get there. 13.28.39 # 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 # mostly to help me test MTP 13.28.51 # e.g., device DateTime property 13.28.53 # but to my point about MTP clients, what is out there that implements media control? 13.29.00 # speachy: no idea 13.29.01 # (or even datetime?) 13.29.03 # i'd have to look 13.29.17 # If you have to end up writing a client to drive that feature, it does diminsh its general usefulness. 13.29.29 # indeed 13.29.38 # the main use of DateTime would be to allow setting the RTC remotely 13.29.46 # which is useful to a point 13.29.57 # I mean, right now the biggest bang-for-buck we could do is get bluetooth going on these hibyos-based targets 13.30.13 # isn't the biggest issue have a BT stack? 13.30.19 # (but damn, what a %@%@# PITA...) 13.30.22 # I was going to ask about that 13.30.59 # still no progress on YH-925 13.31.04 # i'll have to dig into it more 13.31.16 # 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 # speachy: the hotswap feature, what can trigger it? 13.31.49 # just SD card ejection? 13.32.14 # most other storage is considered non-removeable 13.32.22 # braewoods: without plugging it in? Yeah, just ejecting storage. 13.32.41 # i'll need to implement that for MTP 13.32.43 # later on 13.33.17 # 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 # there's actually a LIBRARY for that? 13.34.10 # speachy: what about arduino? any bluetooth stuff we can use from that? 13.34.23 # most of the commercial stacks have been withdrawn from sale. 13.34.45 # braewoods: No "classic" stack to be had. 13.34.55 # i see 13.35.13 # If we cared about BTLE, there are a _lot_ of options, including one I actually worked on in my last gig. 13.35.28 # what's wrong with BTLE? 13.35.51 # afaik it's not capable of audio or anything like that, correct? 13.36.54 # speachy: in any case i'll focus on the main use case 13.36.56 # amachronic: it's a completely different PHY and OTA protocol. Bluetooth only in name. :) 13.37.33 # i will probably add a few trivial extras like DateTime and BatteryLevel 13.37.34 # but there is a new audio-over-BTLE spec. 13.37.57 # they don't require storage access to work 13.38.04 # so small addons 13.38.29 # 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 # 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 # there's no plans for regular wifi 13.39.06 # rockbox lacks a network stack 13.39.19 # TCP/IP more accurately 13.39.27 # amachronic: our best bet at the moment is probably going to involve porting the linux bluez (or android bluedroid) stacks. 13.39.55 # you mean running on Linux? or porting BlueZ into Rockbox kernel? 13.40.13 # amachronic: the latter. 13.41.00 # speachy: did you investigate apache nimble? 13.41.00 # the existing x1000 linux platforms already have bluez 4. Except the m3k. 13.41.13 # 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 # braewoods: the name 'nimBLE' says it all. 13.41.58 # amachronic: yet you chose to do a native x1000 port for the m3k. :) 13.42.36 # ha, a bit silly in retrospect, but the prospect of getting Linux working was too daunting 13.43.40 # not planning on doing any other Rockbox ports soon, but it's something for the future 13.43.43 # 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 # I agree, shanling seemed to do a much better job. 13.44.07 # a shame, because some of the quirks I ran into could be trivially fixed if I had the sources. 13.44.26 # c'est la vie 13.45.00 # is there any plans to update the rockbox UI? for touchscreens etc. 13.45.35 # I think the "plan" is "patches welcome" 13.46.11 # speachy: oh 13.47.51 # (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 # 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 # there's no ability to handle multitouch or gestures. 13.52.09 # 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.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 # 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 # Also the link to the simulator is broken (http://rasher.dk/rockbox/simulator/get.php?file=sandisk-e200-sim-w32.zip) 14.19.57 # 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 # Thanks speachy, just thought I'd mention it 14.21.21 # 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 # so it shouldn't matter. 14.24.32 # 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 # mi4, I think. 14.40.09 # Where would I find that? 14.46.57 # 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 # It worked 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.15 *** Saving seen data "./dancer.seen" 17.27.51 Quit Saijin_Naib (Remote host closed the connection) 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.45 Quit koniu (Ping timeout: 240 seconds) 19.26.36 Quit ZincAlloy (Quit: Leaving.) 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.30.58 Quit MrZeus (Ping timeout: 240 seconds) 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.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)