--- Log for 19.01.114 Server: adams.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 21 days and 7 hours ago 00.01.48 Quit wodz (Quit: Leaving) 00.02.08 # from my understanding, there are no more Archos users among the active devs 00.03.38 # or they just keep a very old build because they think it's not worth upgrading anymore 00.04.25 # well it'd be nice to fork at the next release then 00.04.29 # but we still add some useful features on old players sometimes. Quite recently the Ondio FM got soft key lock 00.05.45 # <[Saint]> There's no reason to not go back and add features that won;t increase the binsize by any considerable amount. 00.05.57 # <[Saint]> ...but, there will also be no obligation for anyone to do so. 00.06.27 # <[Saint]> I'm all for forking out HW codec/charcell and applying only bugfixes and trivial features to that branch. 00.07.13 # <[Saint]> Leaving us the other targets to play with, without fear of breaking ancient, highly restrictive ports, would be very nice. 00.07.55 Join n1s [0] (~n1s@rockbox/developer/n1s) 00.08.25 # <[Saint]> I *don't*, however, want to see them get forked out and then left to rot for all eternity...that would be a huge shame. 00.09.16 # <[Saint]> But in saying that, they've been kept on the brink of brokenness, only being massaged back into line occasionally for an age...so, I'm not sure if anything is really lost. 00.14.54 # <[Saint]> ...being perfectly honest, I think its something we all want, and don't want, simultaneously. No one wants to be the one to push the button, no one wants to be the one that is effectively killing ~13 years of Rockbox history. 00.15.29 # <[Saint]> But, in reality, perhaps euthanasia is better than dying of old age and neglect. 00.15.42 # <[Saint]> Gah...its a sad affair. 00.17.09 # hard decision to take so that means we're probably still be discussing that next year :) 00.18.05 # <[Saint]> I think I may have nailed it with "No one wants to be the one to push the button, no one wants to be the one that is effectively killing ~13 years of Rockbox history." 00.18.34 # <[Saint]> ...that's how I feel about it, at least. I imagine at least a few others feel similarly. 00.19.29 # <[Saint]> There would be a certain beauty, and cleanliness about it, if one of "The Originals" did it. 00.19.47 # <[Saint]> LinusN/Bagder/Zagor 00.19.54 # Current builds of these ports don't see much use so they are already bit-rotting 00.20.06 # <[Saint]> Do we *know* that? 00.20.12 # <[Saint]> Or do we just have no reports? 00.20.19 # that's what I was saying above 00.20.25 # there are no download stats AFAIK 00.20.31 # bagder can probably get the download stats 00.20.34 # hes posted them before 00.20.41 # <[Saint]> That would be interesting. 00.20.59 # <[Saint]> (I wonder if it can also filter unique downloads) 00.21.10 # [Saint]: last time o saw stats the archos builds were pretty low 00.21.47 # <[Saint]> Right. I wasn't necessarily saying you were wrong. I just didn't know if we know it for a fact, or if we just all felt that way. 00.22.35 # http://daniel.haxx.se/blog/2008/05/15/rockbox-downloads-april-2008/ 00.22.39 # for reference 00.22.52 # that's almost six years ago :) 00.22.56 # * [Saint] doesn't see thos enumbers increasing. 00.23.09 # <[Saint]> It actually built then too. :) 00.23.48 # yeah the downloads are sure to have dropped since the recorder stopped building... 00.24.07 # * [Saint] decides we should make the RSB do it 00.24.25 # <[Saint]> (do we actually have one, technically, or is it still the last lot since we didn;t renominate?) 00.24.28 # could still check releases 00.24.53 # I'd probably drop them at this point 00.24.59 # but seriously, the low numbers + few reports from users + the fact that the majority of added features are not relevant/available on hwcodec 00.25.11 # can the build system handle two branches by the way? 00.25.16 # [Saint]: I guess it is still the last lot until the next election, whenever that might be 00.25.21 # um, make the case as imo 00.25.29 # <[Saint]> AlexP: right, thanks. 00.25.49 # Which I think might include me now I think about it 00.26.16 # <[Saint]> ...sad as it may be, it does seem we've reached a consensus. We're all thinking the same way, well, almost. 00.26.23 # Unless there has been an election I didn't notice :) 00.26.33 # in terms of developers, who is actually dealing with hwcodec the most? personally none of this has much impact on me since the codecs dont' even build for hwcodec 00.26.34 # <[Saint]> But I think it would be best to go to the ML to let users have a say, and inform them. 00.26.49 # i guess kugel, jdgordon because of the theme engine and buffering 00.26.51 # saratoga_: I'm not sure anyone is 00.26.55 # I need to get a FM recorder and get g#497 merged before any support drop 00.26.57 # 3Gerrit review #497 at http://gerrit.rockbox.org/r/497 : 3 by Jean-Louis Biasini (changes/97/497/3) 00.27.01 # <[Saint]> Amiconn? 00.27.09 # <[Saint]> (2~3 years ago...) 00.27.10 # And those that are it isreally just if it inadvertently breaks 00.27.18 # And by breaks I mean doesn't build 00.27.22 # Not works :) 00.27.39 # g#497 can probably go in 00.27.40 # 3Gerrit review #497 at http://gerrit.rockbox.org/r/497 : 3Add FM softlock to the fm recorder. by Jean-Louis Biasini (changes/97/497/3) 00.27.49 # unless theres some problem i'm not aware of? 00.27.59 # <[Saint]> How would we approach this, we we to handle it in the most transparent way possible? 00.28.06 # <[Saint]> *were we 00.28.53 # saratoga: I tested it for Ondio FM and it got merged. I guess Jean-Louis was just waiting for someone to test 00.29.01 # <[Saint]> I think once the descision has been made that that's the course of action that would inevitable follow, we would need to give the users and less active developers a chance to have a say? 00.29.08 # <[Saint]> Via the forum/ML? 00.29.26 # I don't think users et much of a say tbh 00.29.27 # lebellium: assuming it works fine, i can commit it now 00.29.42 # <[Saint]> AlexP: neither do I...but, we need to make them think they do. 00.29.44 # [Saint]: i'd say bring it to the dev ml let it take enough time for people to think and reply and then perhaps let the rsb decide if no consensus is reached on the ml 00.29.45 # <[Saint]> :) 00.29.52 # But if you would like to try and reach a decision, the dev mailing list would be a good start 00.30.01 # saratoga: it works fine for Ondio FM but I can't say for FM recorder, although I don't see any reason why it would be different 00.30.28 # [Saint]: heh :) I don't see the point though, the odd person who uses it will say no, nobody else will care, and it won't influence any decision 00.30.34 # wrt the user ml that is 00.30.59 # <[Saint]> AlexP: n1s: I think the decision has been made already, and has been for some time, its just finalizing it really. 00.31.04 # actually can someone else push 497? i'm not near a machine with git in case it breaks something 00.31.09 # <[Saint]> I honestly don;t think any active dev is going to oppose this. 00.31.58 # [Saint]: then reaching a consensus on the ml should be easy 00.32.41 # <[Saint]> AlexP: n1s: The main reason I thought it would at least be nice to include users in this decision is the vain hope I have that it might inspire someone to take up maintaining the branch once its forked. 00.32.48 # hah 00.32.54 # <[Saint]> ...I mean, you never know, and I feel I'd have to try before I put this to bed. 00.33.02 # Be my guest :) 00.33.04 # <[Saint]> However unlikely it is. 00.33.32 # * [Saint] is /sometimes/ an optimist, when it suits. :) 00.34.04 # [Saint]: _optimist_ 00.34.20 # <[Saint]> Heh. 00.35.00 # but sure, i wouldn't expect any constructive discussion but if you're willing... 00.35.44 Quit ender` (Quit: I will not use any plan in which the final step is horribly complicated, e.g. "Align the 12 Stones of Power on the sacred altar then activate the medallion at the moment of total eclipse." Instead it will be more along the lines of "Push the button." --) 00.36.26 # <[Saint]> Wow...there's a quit message and a half. 00.39.30 Quit kugel (Ping timeout: 260 seconds) 00.49.33 Quit n1s (Quit: Ex-Chat) 00.56.25 *** Saving seen data "./dancer.seen" 01.15.40 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 27.0/20140116125114]) 01.23.18 # What is in the way of making Archos FM Recorder work? I have one I can either troubleshoot with or loan out. Not quite sure I want to permanently part with it, but I'm glad to ship it away for an extended period if it is really useful for development (and anyone cares...). Or I can use it to try to help fix the issues, if someone wants to help get me up to speed. Why would the HWCODEC be an issue, wouldn't the code for that "just keep working"? 01.24.34 # toehser: the FM recorder is fine, it's the recorder that's troublesome 01.25.09 # It's easy to get building again for a while, just find another feature to drop, but that's not a proper solution 01.25.16 # I thought the FM Recorder was just the Recorder with the Tuner enabled? What was the FM Recorder minus FM called then? 01.26.17 # The issue is that it's too big for the ROM bootloader, which can be solved by moving over to a bootloader / main firmware model like basically every other target 01.26.39 # That shouldn't be *too* hard to do, but someone has to be motivated enough to do the work 01.27.15 # I see, I'm thinking of the "Recorder 20". 01.28.07 # <[Saint]> Is there a bricking risk involved, gevaerts? If so, is there a recovery method? 01.28.25 # No. It's about loading from disk 01.28.39 # The other issue is that HWCODEC has a rather different playback engine which can cause issues sometimes, and which annoys people 01.28.44 # So, it means writing a new bootloader for something that no-one uses... I see the problem. 01.29.50 # If you fork it, it is dead, might as well just declare a version that is the 'last archos version', nobody is going to be fixing and working on it if you fork it... I agree with that. 01.29.52 # And then of course there are things like a possible future new plugin loader that would allow neat stuff, which does include CPU architecture specific bits, where again Archos is different 01.30.10 # And of course there's the Player with its charcell screen :) 01.33.35 # toehser: I very much doubt if shipping devices to people will help here. People who care about the old Archoses usually have a few of them lying around 02.01.58 Join nosa-j [0] (~m00k@66.233.224.206) 02.06.24 # should i keep closing fs tasks for AMS usb bugs or just let people keep making them 02.06.31 # i guess in theory they may be different issues 02.26.23 # <[Saint]> IS it known to be resolved now? 02.26.42 # <[Saint]> "the main one", that is. Themes randomly totally fucking USB. 02.27.55 # * JdGordon wouldnt shed a tear if we dropped charcell 02.30.45 # <[Saint]> You've been pretty impassioned on the subject in the past, perhaps you want to be the one to bring it up formally on the ML then? :) 02.35.07 # i don't think usb is fixed, but we already have a bunch of tasks open for it 02.35.18 # <[Saint]> ah, right. 02.35.49 # <[Saint]> we actually need to be thinking about freezing, RC builds, and a release. 02.36.03 # <[Saint]> We need AMS testers for git HEAD. 02.36.21 # <[Saint]> Specifically people that saw the theme/USB shennanigans. 02.56.26 *** Saving seen data "./dancer.seen" 02.58.49 Quit saratoga_ (Quit: Page closed) 03.06.06 Quit Rower (Quit: Hmmm...) 03.10.31 Join Strife89 [0] (~Strife89@adsl-98-80-237-249.mcn.bellsouth.net) 03.47.35 # Anyway git HEAD works fine on my AMSs. 03.50.08 # <[Saint]> PurlingNayuki: Don;t you use a unix host OS, though? 03.50.35 # <[Saint]> (It seems to be Windows specifically that has issues) 03.54.16 # I have Windows for games, Debian for working and study, and had OSX for music stuffs. 03.55.51 Join draba [0] (~draba@s1106232.xgsspn.imtp.tachikawa.spmode.ne.jp) 03.57.47 # USB to the internal storage seems to work fine for me now, but I've seen what seems like more issues to the card, I'll try that some... 04.03.04 # <[Saint]> I guess we just need to hear from lebellium, then. 04.04.01 # <[Saint]> His "samsunglike" theme is apparently an almost guaranteed way to scre up USB on AMS. 04.04.10 # <[Saint]> *screw up 04.13.55 # Why there's no lang APIs for plugins? 04.42.57 Quit amiconn (Disconnected by services) 04.42.57 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.42.57 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.42.57 Quit pixelma (Disconnected by services) 04.42.58 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.43.01 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.50.38 Quit draba (Ping timeout: 264 seconds) 04.54.34 Quit Strife89 (Ping timeout: 246 seconds) 04.54.35 Join bitz [0] (~spencer@c-71-56-150-252.hsd1.wa.comcast.net) 04.54.51 Quit bitz (Client Quit) 04.56.27 *** Saving seen data "./dancer.seen" 04.58.15 Join X2000 [0] (~spencer@c-71-56-150-252.hsd1.wa.comcast.net) 05.04.58 # Question: I'm running Liniux and am trying to build Rockbox form source. I can generate a makefile but every time I try to build it I get an error saying that a file called lang.h cannot be found. Google hasn't turned up any helpful results and I can't find the file anywhere in the Rockbox soure direcotry. Where do I get lang.h from? 05.07.54 # <[Saint]> Are you sure you meet the build requirements? That may cause odd issues I imagine. 05.07.58 # <[Saint]> one sec. 05.08.14 # <[Saint]> Apart from a base system, all we need should be "automake bison build-essential ccache flex libc6-dev libgmp3-dev libmpfr-dev libsdl1.2-dev libtool texinfo" 05.09.02 # <[Saint]> that's for binaries/simulator, manuals need slightly more. 05.09.14 # Yeah I already went through and installed all those while trying to run rockboxdev.sh 05.09.49 # <[Saint]> WHat target are you trying to build for? 05.10.04 # ipod video 05.13.38 # <[Saint]> working fine here. 05.14.35 # <[Saint]> WHat do you mean "while /trying/ to run rockboxdev.sh"? 05.15.00 # <[Saint]> That part is kinda critical, you need the armeabi toolchain, there's no avoiding it. It needs to suceed. 05.15.57 # <[Saint]> Also, is this a clean working checkout? 05.16.22 # <[Saint]> (if there are patches applied, which? can you build without them, have you checked?) 05.16.36 # every time I tried to run it, it would say cnnot run without (package), I installed the package it asked for and repeated until it ran sucesfully 05.17.51 # <[Saint]> massaging a base system until a toolchain builds doesn;t necessarily mean you have all required components to build Rockbox binaries proper. 05.18.12 # I'm trying to start work on a plugin I have in mind. right now I'm just trying to build an unmodified version of the source form git 05.18.34 # <[Saint]> If you haven't done so expressly, I would recommend "sudo apt-get install automake bison build-essential ccache flex libc6-dev libgmp3-dev libmpfr-dev libsdl1.2-dev libtool texinfo" 05.19.00 # <[Saint]> Or pacman, or yum, or aptitude...whatever floats your boat. 05.19.28 # thank you apperently build essential wasn't installed. I'll try it now. 05.20.26 # nope same error 05.21.09 # <[Saint]> make veryclean in the build directory, then reconfigure and try again. 05.21.41 # <[Saint]> that is the command "make veryclean", and then rerunning configure for the target. 05.22.15 # seems to be working. Thank you so much 05.22.22 # <[Saint]> Not a problem. 05.25.20 # Is FS#12074 fine to commit? Though we can't detect lineout, it's still possible to let users to choose. 05.25.20 # http://www.rockbox.org/tracker/task/12074 3Add setting to enable/disable lineout on Sansa Fuze V2 (patches, unconfirmed) 05.25.44 Part X2000 ("Konversation terminated!") 05.28.04 # <[Saint]> Comment by MichaelGiacomelli (saratoga) - Monday, 03 December 2012, 15:49 GMT 05.28.04 # <[Saint]> Hi Rawl, 05.28.04 # <[Saint]> We won't be including this in the main build until someone reverse engineers the mechanism for detecting if a line out dock is connected. 05.28.42 # <[Saint]> The setting hijacked here also isn't appropriate. 05.28.59 # <[Saint]> That setting is used to *power off* the lineout feature, not to switch to or from it. 05.38.20 # ..Oops 05.38.30 # New settings? 05.38.42 # Should a new setting be added? 05.39.19 # <[Saint]> Argh. Its hard to tell, but the last two lines there are from myself, no from the comment. 05.39.22 # Why auto detect is needed to add this to main build? 05.39.51 # I haven't gotten a USB related failure for a long time... maybe it is fixed. 05.40.04 # <[Saint]> Anyway, I'm not sure that would help matters. As using a new setting doesn't seem to help the fact that there was opposition to this until such time as the line out state could be detected. 05.41.07 # <[Saint]> Autodetecting of the lineout state is the way its handled on every other target we can use the lineout on, as far as I know. 05.41.45 # <[Saint]> ANd the only lineout related setting is for disabling lineout completely (potentially saving battery). 05.42.35 # <[Saint]> It would seem weird to handle it different for one particular target. And it would inevitably lead to situations where the user forgets which output is enabled and wonders why one or the other won't work. 05.42.36 # Currently we set the AMS lineout to powered off IIUC. 05.43.16 # Nope. They set this themselves so they will remember. 05.43.22 # Just like volume cap. 05.43.29 # <[Saint]> Unfortunately, that's not how users work. 05.43.58 # <[Saint]> At least the volume cap provides some form of visual hint due to the reduced maximum volume. 05.44.50 # Why doesn't "backdrop: -" in the theme cfg file always clear the backdrop from a previous theme? Is there some other way to clear it? 05.44.50 # <[Saint]> You could certainly try to get this patch included (with a new setting), but I think it would just hit the same wall as it did initially. 05.45.22 # <[Saint]> toehser: it _should_. 05.45.28 # <[Saint]> Not doing so is a bug. 05.45.31 # doesn't though 05.45.34 # reproducable 05.45.53 # <[Saint]> You know what to do. :) 05.47.37 Join danielf [0] (~danielf@c-71-202-175-244.hsd1.ca.comcast.net) 05.50.18 Quit danielf (Client Quit) 05.50.38 Join danielf [0] (~danielf@c-71-202-175-244.hsd1.ca.comcast.net) 05.50.56 Nick danielf is now known as qsylalyn (~danielf@c-71-202-175-244.hsd1.ca.comcast.net) 05.53.54 Quit qsylalyn (Client Quit) 05.54.59 Quit TheSeven (Disconnected by services) 05.55.13 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 06.00.44 # k. I filed a bug. Weird thing: Load cabbiev2 theme, then tomsway2: backdrop cleared. Load 3_eyed_jack theme, then tomsway2: backdrop not cleared. 06.14.52 # For that matter, load 3_eyed_jack, then load cabbiev2, backdrop stays 3_eyed_jack. 06.39.43 Join leftright [0] (c5e01404@gateway/web/freenode/ip.197.224.20.4) 06.40.49 # H140: Bug; latest dev build still exhibits the following bug, FS#12769 - rb 3.12 06.40.50 # http://www.rockbox.org/tracker/task/12769 3rb 3.12 - iriver H140 bootloader crash: 1st boot fails, Reset pin, 2nd boot Successful. Repeatable. (bugs, unconfirmed) 06.54.55 # [Saint]: Reset lineout after reboot should be fine to users. 06.55.23 # If they find no phone output most of they will try rebooting first. 06.55.39 # <[Saint]> I'm not sure we have any user settings that are gleefully ignored on a reboot. 06.55.48 # <[Saint]> That seems..rather disgusting. 06.56.14 # <[Saint]> Well, not just ignored, *reset*. 06.56.28 *** Saving seen data "./dancer.seen" 06.56.56 # <[Saint]> Nothing should ever do that in our current system, and I don't think anything does, because its kinda hideous. 06.58.25 # <[Saint]> This is why it kinda needs to detect the lineout state, so it "Just Works". 07.13.06 Quit leftright (Quit: Page closed) 07.24.34 # Actually there is. 07.24.59 # Sleep timer does that in fact, they will be reset on every boot. 07.54.13 Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 07.55.23 Join Gallomimia_ [0] (~gallomimi@99.199.8.77) 08.05.36 Join draba [0] (~draba@s1106097.xgsspn.imtp.tachikawa.spmode.ne.jp) 08.24.34 Join Unhelpful_ [0] (~quassel@rockbox/developer/Unhelpful) 08.24.40 Join KiwiCAM_ [0] (~quassel@121.99.184.8) 08.24.50 Join Mir_ [0] (~Mir@pool-71-109-219-225.lsanca.dsl-w.verizon.net) 08.25.53 Quit zoktar (Ping timeout: 264 seconds) 08.25.53 Quit albb0920 (Ping timeout: 264 seconds) 08.25.53 Quit ladyblink (Ping timeout: 264 seconds) 08.25.53 Quit gelraen (Ping timeout: 264 seconds) 08.25.54 Quit Mir (Ping timeout: 264 seconds) 08.25.54 Quit pystar89 (Ping timeout: 264 seconds) 08.25.54 Quit ranmachan (Ping timeout: 264 seconds) 08.25.59 Join gelraen [0] (~imax@lab.biomed.kiev.ua) 08.26.01 Join zoktar [0] (~zoktar@78-72-44-158-no186.tbcn.telia.com) 08.26.02 Quit kiwicam (Ping timeout: 264 seconds) 08.26.03 Quit Unhelpful (Ping timeout: 264 seconds) 08.26.03 Quit froggyman (Ping timeout: 264 seconds) 08.26.03 Quit zoktar (Changing host) 08.26.03 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 08.26.10 Join ranmachan [0] (ranma@kagami.uguu.de) 08.26.13 Nick Mir_ is now known as Mir (~Mir@pool-71-109-219-225.lsanca.dsl-w.verizon.net) 08.26.46 Join ladyblink [0] (bassgeisha@selectah.drop.that.bass.aikyou.bassgeisha.com) 08.32.15 Join froggyman [0] (~frogs@unaffiliated/froggyman) 08.45.03 Join albb0920 [0] (~albb0920@140.115.83.1) 08.45.39 Join n1s [0] (~n1s@rockbox/developer/n1s) 08.48.41 Join danielf [0] (~danielf@c-71-202-175-244.hsd1.ca.comcast.net) 08.48.58 # gevaerts: While moving over to a bootloader model as such isn't difficult, it's a bit more involved to make it work for both flashed and non-flashed install, and to make sure the flash image transition is safe 08.50.36 # That means each model should be thoroughly tested. I do have access to Player, Recorder, Ondio SP and Ondio FM, but not FM Recorder and Recorder v2. The last two are identical apart from the model flag though, so having access to either one should be sufficient 08.51.43 # In theory, one should also test with bootrom and non-bootrom variants, but I never came across one of the latter 08.51.58 # [IDC]Dragon did, but he's not been around for years 08.52.23 Quit danielf (Client Quit) 08.52.43 Join danielf [0] (~qsylalyn@c-71-202-175-244.hsd1.ca.comcast.net) 08.53.08 Nick danielf is now known as qsylalyn (~qsylalyn@c-71-202-175-244.hsd1.ca.comcast.net) 08.55.35 Quit [Saint] (Remote host closed the connection) 08.56.30 *** Saving seen data "./dancer.seen" 08.57.15 Quit qsylalyn (Client Quit) 08.57.33 Join qsylalyn [0] (~qsylalyn@c-71-202-175-244.hsd1.ca.comcast.net) 08.57.42 Join [Saint] [0] (~saint@rockbox/staff/saint) 09.08.58 Quit qsylalyn () 09.09.11 Join pretty_function [0] (~sigBART@123.252.214.163) 09.09.13 Join qsylalyn [0] (~qsylalyn@c-71-202-175-244.hsd1.ca.comcast.net) 09.10.15 Quit qsylalyn (Remote host closed the connection) 09.10.26 # Anyway to upgrade Clip zip's firmware from 01.20.21 to 01.20.21? 09.10.49 Join qsylalyn [0] (~qsylalyn@c-71-202-175-244.hsd1.ca.comcast.net) 09.11.23 # <[Saint]> PurlingNayuki: Why would you? 09.11.56 # I modified the bootloader a little to adapt my using habit 09.12.41 # I was on 01.20.21 already before and I use the same version to patch bootloader, rename it to clzpa.bin and put it in the root 09.13.09 # But after disconnect the USB it just goes to update database, no firmware upgrading. 09.14.34 Join rela [0] (~x@pdpc/supporter/active/rela) 09.15.23 # * PurlingNayuki is trying to flash the OF back and rockbox it again. 09.16.45 # <[Saint]> As far as I am aware, the firmware shouldn;t care if it is updating to the same, or lesser, version. 09.17.09 # Oops I know the reason why 09.17.41 # Stupid me, the file name should be clpza rather than clzpa 09.30.25 Quit qsylalyn () 09.39.51 Join sprout_n1w [0] (~Rob@180.168.176.99) 09.43.50 Quit Gallomimia_ (Read error: Connection reset by peer) 09.44.37 Join Gallomimia_ [0] (~gallomimi@99.199.8.77) 10.01.10 Join ender` [0] (krneki@foo.eternallybored.org) 10.06.01 Quit sprout_n1w (Quit: leaving) 10.19.47 Quit [Saint] (Remote host closed the connection) 10.21.49 Join [Saint] [0] (~saint@rockbox/staff/saint) 10.29.08 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 10.32.45 Join pystar89 [0] (~pystar89@ip-109-90-154-150.unitymediagroup.de) 10.44.07 # updated my usb ticket 10.44.23 # connecting clip+ while turned off - sansa connects as usb1.0 ) 10.44.38 # linux case. 10.44.47 # win7 all fine with it. 10.53.31 Quit rela (Read error: Connection reset by peer) 10.56.34 *** Saving seen data "./dancer.seen" 10.58.37 Quit draba (Ping timeout: 252 seconds) 11.04.48 Quit pretty_function (Remote host closed the connection) 11.26.47 Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) 12.13.24 Quit Gallomimia_ (Quit: Gallomimia_) 12.19.31 # Baranko: for the record, full speed is still usb 2.0, and there are *very* few 1.0 devices around (1.1 is much more common) :) 12.21.24 # <[Saint]> I don't think I remember the last time I saw 1.0 in the wild. 12.21.32 # <[Saint]> (in use) 12.21.45 # [Saint]: mice and keyboards 12.23.53 # <[Saint]> Not mine, that's certain. 12.24.04 # copper: 1.*0*? 12.24.06 # 1.1, sure 12.24.25 # <[Saint]> even that's fading out. 12.24.42 # ah 12.24.58 # 1.1 was basically a bugfix release. There's not been any good reason to ever use 1.0 since 1.1 was released 12.26.19 # And the step from 1.1 to 2.0 for low and full speed devices is also reasonably small. You need to change the version number, and I think you may need an extra descriptor, but that's more or less it 12.26.43 Join rela [0] (~x@pdpc/supporter/active/rela) 12.27.02 # <[Saint]> Its quite confusing at first. 12.27.08 # Of course, for a mouse or something like that, that might mean having to update firmware that's been fine since 1998 and isn't actually broken, so why bother? :) 12.28.48 # [Saint]: it's fairly straightforward now, but once we have superspeed devices we'll have to explain that while full speed *is* usb 2.0, high speed is not USB 3.0 :) 12.30.21 # <[Saint]> "full speed" was rather short sighted, I guess. :) 12.30.49 # so was high speed, for that matter :) 12.30.57 # there's plenty of room beyond full speed, like super, hyper, ultra, etc. :) 12.31.09 # "Fuller speed" and "Fullest speed" would have been better 12.31.10 # <[Saint]> über 12.31.40 # well 12.31.56 # since we're currently at "super speed", I assume USB 4.0 will be "mega speed" 12.32.15 # <[Saint]> we could shorten it to ÜSB 12.32.18 # copper: we can't know! 12.32.29 # [Saint]: haha, nice 12.32.33 # It may be mega speed, or it may be super speed *or* mega speed! 12.32.36 # I would totally vote for that 12.32.58 # We don't know if they'll refer to the 3.0/2.0 specs for lower speeds or include them in the 4.0 spec 12.33.39 # <[Saint]> "fuller than full speed but not quite the fullest speed" 12.33.56 # <[Saint]> ...has a ring to it. 12.50.09 Join leftright [0] (c5e01404@gateway/web/freenode/ip.197.224.20.4) 12.51.47 # hi. Is mr. Someone perhaps reviewing this bug FS #12769. if not please update the falsh web page stating that flash only works up to v3.8 12.53.13 # thats on the H1xx series 12.53.53 Quit leftright (Client Quit) 12.56.38 *** Saving seen data "./dancer.seen" 13.03.07 Join mortalis [0] (~mortalis@77.108.98.176) 13.08.43 # <[Saint]> Oh. That was cute. 13.09.12 Quit rela (Read error: Connection reset by peer) 13.09.47 # <[Saint]> I think it might take a /wee/ bit longer than expected. 13.21.30 Join arcolight [0] (5c6414a3@gateway/web/freenode/ip.92.100.20.163) 13.27.00 # Hello. I have a question about rockbox utility and packaging for Debian. I've read on official site, that there are no official packages for different linux distributions. I'm using Debian stable and I want to install rbutil as package. If i want to creaqte deb-package, should I create build scripts and send them to developers or they don't interested in this and I should only created package and post them on official site? 13.27.23 # Sorry for my English, it's not my native language. 13.30.17 Join juda [0] (~brakha@2a01:e34:ee9a:fc30:5ceb:3c55:afaf:953f) 13.30.25 # bonjour 13.30.50 # j'aurais voulu avoir plus d'information sur rockbox et mon lecteur mp3 13.31.33 # et si c'est possible d'effectuer le changement, comment on fait sur linux? 13.34.06 # juda: do you speak english? 13.34.24 # okay 13.34.39 # what is your MP3 player? 13.34.58 # memup 13.35.29 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 13.35.30 # it's not supported by Rockbox, sorry 13.35.58 # okay 13.38.13 Part arcolight 13.38.50 Join arcolight [0] (~arcolight@ppp92-100-20-163.pppoe.avangarddsl.ru) 13.41.07 # <[Saint]> arcolight: as long as you conform to the license requirements, you can do whatever you want. 13.55.08 Join eyfour [0] (~eyfour@176.76.202.84.customer.cdi.no) 13.58.20 Quit eyfour (Client Quit) 13.58.26 Quit arcolight (Quit: Konversation terminated!) 13.59.33 Join arcolight [0] (~arcolight@ppp92-100-20-163.pppoe.avangarddsl.ru) 14.02.51 Join eyfour [0] (~eyfour@176.76.202.84.customer.cdi.no) 14.03.11 Part eyfour 14.13.21 Quit ikeboy (Quit: ikeboy) 14.13.53 Part arcolight ("Konversation terminated!") 14.24.03 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 14.26.16 # gevaerts: at all, i don't remember which of them right 14.26.37 # i see that speed musch differs and dmesg shows that now it's only full speed 14.26.49 # and want's to be connected to high speed 14.29.01 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 14.33.07 Join lebellium [0] (~chatzilla@194.240-65-87.adsl-dyn.isp.belgacom.be) 14.36.05 Quit ikeboy (Quit: ikeboy) 14.45.57 Join Strife89 [0] (~Strife89@adsl-98-80-237-249.mcn.bellsouth.net) 14.49.41 # <[Saint]> I can create the same effect by connecting an iPod Video while the disk is spinning. 14.56.41 *** Saving seen data "./dancer.seen" 15.17.18 Quit lebellium (Ping timeout: 252 seconds) 15.21.24 Join lebellium [0] (~chatzilla@194.240-65-87.adsl-dyn.isp.belgacom.be) 15.41.51 Quit Strife89 (Ping timeout: 252 seconds) 15.52.29 Part juda ("Quitte") 16.05.11 Join kugel [0] (~kugel@91-64-116-250-dynip.superkabel.de) 16.05.11 Quit kugel (Changing host) 16.05.11 Join kugel [0] (~kugel@rockbox/developer/kugel) 16.14.50 # does anyone know speex? 16.19.05 # It's a speech oriented audio codec, but that's not important right now. 16.31.46 # copper: right 16.31.56 # I've got a question on how to use it 16.56.44 *** Saving seen data "./dancer.seen" 17.10.08 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 27.0/20140116125114]) 17.11.01 Join lebellium [0] (~chatzilla@194.240-65-87.adsl-dyn.isp.belgacom.be) 17.25.43 # Looks like i found some dependencies. But as for me it looks very strange, 17.25.43 # Using linux box. 17.25.44 # If i insert card transcend 4gb 6 class and copy 3gb data into internal memory of player (sd memory mounted too, but not used) all goes fine. 17.25.44 DBUG Enqueued KICK Baranko 17.25.44 # If i insert card transcend 32gb 10 class and copy 3gb data into internal memory of player (sd memory mounted too, but not used) all goes bad, sansa disconnects, hangs etc. 17.26.10 # don't know how it could be, but i reproduce it right here right now. 17.35.54 Join krabador [0] (~krabador@unaffiliated/krabador) 18.04.29 Join krabador_ [0] (~krabador@host139-190-dynamic.41-79-r.retail.telecomitalia.it) 18.04.46 Quit krabador (Ping timeout: 260 seconds) 18.08.23 Quit krabador_ (Client Quit) 18.10.24 Join krabador [0] (~krabador@unaffiliated/krabador) 18.11.21 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 18.16.39 Quit krabador (Quit: Sto andando via) 18.17.46 Quit Baranko (Quit: Ухожу я от вас) 18.23.34 Join krabador [0] (~krabador@unaffiliated/krabador) 18.30.06 Quit ParkerR (Ping timeout: 240 seconds) 18.30.06 Quit habys (Ping timeout: 240 seconds) 18.30.07 Quit Karrde (Remote host closed the connection) 18.30.08 Join ParkerR [0] (ParkerR@withg.org) 18.30.51 Quit ParkerR (Changing host) 18.30.51 Join ParkerR [0] (ParkerR@unaffiliated/parkerr) 18.35.06 Quit krnlyng (Ping timeout: 260 seconds) 18.40.50 Join habys [0] (~luke@50.73.79.113) 18.50.19 Join krabador_ [0] (~krabador@host246-184-dynamic.20-87-r.retail.telecomitalia.it) 18.50.58 Quit mortalis (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 18.51.26 Quit krabador (Ping timeout: 260 seconds) 18.56.48 *** Saving seen data "./dancer.seen" 18.59.52 Quit uwe_ (Ping timeout: 252 seconds) 19.00.45 # HEAD no longer reads APEv2 tags (example file: https://outpost.fr/tmp/e5G.mpc ) 19.00.51 Quit krabador_ (Quit: Sto andando via) 19.01.12 # well, sim doesn't read them 19.01.16 Join krabador [0] (~krabador@unaffiliated/krabador) 19.01.56 # and my actual Fuze+ craps out when trying to play some MPC files (playback stops) 19.02.04 # I've checked the integrity of my files 19.10.41 # hmmm 19.10.52 # the sims definitely don't read APEv2 tags 19.10.56 Join uwe_ [0] (~uwe_@dslb-088-066-160-105.pools.arcor-ip.net) 19.10.56 # my Fuze+ does 19.11.04 # I'm trying to reproduce the playback issue 19.13.44 Quit Rower (Ping timeout: 272 seconds) 19.13.50 # damn it 19.13.57 # works fine from the internal storage 19.20.27 # meh 19.20.37 # can't reproduce it either from the microsdxc card 19.20.44 # database fuck up maybe 19.31.33 Quit krabador (Quit: Sto andando via) 19.36.37 Join W00fer [0] (~W00fer@a80-101-149-96.adsl.xs4all.nl) 19.37.01 # Hello, someone here working on RK27XX port? I have some information I can share 19.42.11 # yup, database fuckup again 19.42.28 # and when the database is fucked up, "initializing" it from Rockbox doesn't help 19.42.45 # I know something's wrong when initializing the database takes a lot longer than usual 19.42.51 Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) 19.42.57 # the fix is to delete it completely and THEN initialize it 19.43.05 # delete the database files I mean 19.47.05 Join krabador [0] (~krabador@unaffiliated/krabador) 19.57.24 Join Strife89 [0] (~Strife89@adsl-98-80-237-249.mcn.bellsouth.net) 19.58.59 Join krnlyng [0] (~liar@83.175.90.24) 20.19.19 Quit APLU (Ping timeout: 252 seconds) 20.20.36 Quit uwe_ (Ping timeout: 272 seconds) 20.25.40 Join Karrde [0] (alucard@karrde.kiserai.net) 20.32.10 Join APLU [0] (~mulx@2a01:e34:ee29:12b0::10) 20.33.20 # n1s: looking forward to your opus improvements :) 20.33.49 Quit Strife89 (Ping timeout: 264 seconds) 20.34.26 # bertrik: i haven't really done anything this time around, just imported jmspeex' optimizations, so far 20.35.02 # i think saratoga is planning to write some arm asm for the fft which should speed it up quite a bit i think 20.36.58 # yeah i have some asm working nicely for the pre-1.1 code 20.37.08 # its broken on the current git though, and i haven't had time to figure out why 20.37.28 # just simple stuff to help me remember armv4 :) 20.37.42 # Is theer a way to erase the databse from the RB menus? 20.38.19 # yeah, the initialize database option erases and then rebuilds it from scratch i believe 20.40.18 # Thanks. 20.41.28 # on a side note, i wonder if parts of the mdct could be shared between opus and our core mdct lib 20.41.45 # normally we can't use the mdct lib because opus uses non-power-of-2 transforms 20.42.01 # but i guesss the rotation code, which is actually fairly slow, could be made to work with both 20.42.03 Join uwe_ [0] (~uwe_@dslb-088-066-160-105.pools.arcor-ip.net) 20.42.08 # saratoga: like I said, "initialize" doesn't always work as expected 20.42.22 # no idea why 20.42.52 # I've had that database re-initialization bug for a long time 20.43.39 # it's hard to reproduce, because one first has to cause the DAP to crap out when connected via USB 20.43.53 # and then I don't know what kind of "crapping out" causes the database bug 20.44.27 # does "initialize" really, physically delete all database files before rebuilding it? 20.54.51 # i'm not familiar with the code so i don't know for sure 20.56.43 # it calls remove() on database_idx.tcd and database_N.tcd 20.56.51 *** Saving seen data "./dancer.seen" 20.57.00 # it doesn't seem to do anything with database.log, not sure that's relevant 20.57.17 # doesn't touch database.ignore either 20.57.21 # the database.log is only made if you ahve that debug option enabled 20.57.30 # database.ignore just tells the database not to scan that folder 20.57.42 # IIRC 20.57.58 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 20.57.58 # * gevaerts nods 20.58.13 # database.ignore is not at all part of the database 20.58.34 # W00fer: I did some work on rk27xx but the main dev is wodz 20.58.35 # Removing it on database cleanup would be a rather serious bug 20.58.51 # It's similar to .nomedia on android and the like 20.58.53 # W00fer: he usually reads the logs 20.59.00 # then I don't know what's wrong 21.03.03 # perhaps a rebuild while the device is running triggers some bug that doesn't happen when its first booted? 21.03.11 # memory corruption perhaps? 21.04.02 # hmmm, I'm pretty sure I do reboot first, then connect via USB, then erase the files, unplug, reboot, initialize 21.04.08 # (so yeah) 21.04.40 # er 21.04.50 # I mean, I do all that, to make sure I don't run into the bug 21.05.20 # next time I'll try to think of making a copy of the screwy database files 21.05.38 # and upload them for one of you guys to analyze 21.06.54 # saratoga: does the main symptom ring any bells? "Initialize" that adds files a lot slower than normal. 21.07.07 # like 10 times slower 21.07.21 # no idea 21.07.26 # i don't know anything about the database 21.11.46 Quit y4n (Quit: only amiga makes it possible) 21.20.29 Quit APLU (Ping timeout: 272 seconds) 21.24.40 Join APLU [0] (~mulx@2a01:e34:ee29:12b0::10) 21.42.09 # saratoga, n1s: do you know a bit about speex? 21.53.28 # * [Saint] kinda expects saratoga to, for some reason. 21.54.16 Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) 21.54.28 # W00fer: yes? 21.58.51 # kugel: not really, preglow did most of the work on it when i first joined the project 21.58.54 # what did you want to know 21.59.19 # saratoga: I want to feed talk clips in chunks to the speex decoder 21.59.57 # sorry i don't know much about that 22.00.04 # you want me to ask preglow ? 22.01.27 # sure 22.01.59 # I guess I need to align the chunks to frame/packet size but I don't know how to do that 22.02.14 # what are you ultimately hoping to do? 22.02.58 # have the talk clips on buflib and copy the to-be-decoded data to a small static memory area 22.03.33 # where are tehy now? 22.03.53 # on the audio buffer together with buffered audio data 22.05.30 # a) I would like to decouple this and b) the clip cache scheme for lowmem is very inefficient 22.06.13 Quit lebellium (Ping timeout: 264 seconds) 22.06.48 # well, actually I pushed the part that decouples it 22.07.37 # but to improve b) I would like to allocate clips individually with buflib (now there is one large alloc for all clips & thumbnails) 22.10.03 # gevaerts: The guy is right about hd300 recovery after flashing bad bootloader. There are some catches but generally if the code doesn't crash too early it is possible to recover this way. 22.10.48 # <[Saint]> If its not a guaranteed method, though, gevaerts was right to say what he did. 22.11.10 Join lebellium [0] (~chatzilla@194.240-65-87.adsl-dyn.isp.belgacom.be) 22.11.42 # [Saint]: bootloader must be screwed in very sever way for this to not work 22.12.16 # <[Saint]> Right. But as long as its not a guaranteed method, its just as dangerous as the AMS recovery wiki page in my eyes. 22.12.23 # [Saint]: I recovered like dozen times bootloader on MPIOs that way 22.13.06 # [Saint]: Basically you have nothing to lose if you flash bad bootloader. The only alternative is to reflash with BDM 22.14.44 # well, you can do hardcore things like swaping nor flash also :-) 22.14.46 # <[Saint]> Maybe I parsed it differently, but I read it as a Buzfeed post: "Find one weird HW recovery trick the MP3 fatcats DON'T WANT YOU TO KNOW!" 22.15.05 # <[Saint]> It just...I dunno, it made it seem like recovery was always trivial, and we just didn;t know it yet. 22.15.18 # <[Saint]> I think gevaerts was right to add some caution to it. 22.17.04 # Yes and no. It *should* be documented as it allows to easily recover in most situations. No because I didn't know it is possible until I f*** up the bootloader on BDM enabled device and observed what is actually happening 22.18.10 # <[Saint]> I would have absolutely no problem with the information being added to the wiki if it came with a similar warning as the AMS unbrick page. 22.18.17 # and it works ONLY because of checks in rockbox bootloader 22.18.49 # wodz hi 22.18.51 # <[Saint]> ie. "Not an exact science, may not work at all, the best advice is to flash known good code" 22.19.01 # W00fer: hi 22.19.03 # <[Saint]> At your own risk, etc. 22.19.12 # i have bought a rk2706 player 22.19.19 # and extracted the firmware partition 22.19.29 # so if you are interested 22.19.47 # i'm doing now some inquiry about the characteristics of the firmware 22.20.16 # but i need some help as well to progress further 22.20.33 # [Saint]: Do we encourage people to try random bootloaders or we STATE LOUD TO STICK WITH TESTED BUIKD== 22.20.46 # s/BUIKD==/BUILD/ 22.21.05 # pamaury thanks 22.21.11 # W00fer: What you want to know? 22.21.23 # i have seen your work on the tracker and read the logs where you stated rk27xx questions 22.21.47 # maybe it's better over pm wodz 22.21.55 Join BobJonkman1 [0] (~BobJonkma@206-248-137-186.dsl.teksavvy.com) 22.22.14 # W00fer: we usually keep discussion public 22.22.15 # <[Saint]> wodz: ...I, I'm not even sure why you're asking me that. 22.22.38 # <[Saint]> I thought for sure my intentions there are clear. 22.23.36 # okay then i'll try to ask it 22.23.43 # here 22.23.51 # would you like to have my firmware? 22.23.55 # for development 22.24.03 # questions 22.24.15 # W00fer: I am not particularly interested. 22.24.49 # 1: how to update the firmware, as i have read that just overwriting the firmware partition and rebooting boots back to old 'stock' firmware 22.25.07 Join Soukyuu [0] (~Soukyuu@p57B0DF79.dip0.t-ipconnect.de) 22.25.09 # 2: how to test rockbox safe, without messing with official firmware (it has SD slot) 22.25.47 # 3: is there anything i can do to post some info about my device so touchscreen controllers can be investigated? I have seen on the wiki that no info was present on chipsets of rk27xx players 22.25.55 # without opening that is 22.26.27 # 4: are there any safe scsi commands that do not brick my player for testing. I have some limited linux experience 22.27.32 # anyway: i tried some investigating with rk27 device manager and it identifies properly. Because i don't know C, nor make i cannot decompile/decompress rk27boot.bin as I have seen on various sites 22.27.47 # it's version 16.24, which is newer than on most information available 22.27.51 # W00fer: The easiest way to test rockbox (or anything else) is to force the player into RKDFU mode and use rk27load to send arbitrary binary to the device. Unfortunately usually this involves opening the device. There is custom scsi command which in theory should force dfu mode but I it doesn't work on my device. 22.28.09 # uhm 22.28.17 # I have external RESET button 22.28.29 # if i press that with connecting 22.28.34 # does it set DFU mode? 22.28.48 # i have now the following: 22.29.48 # W00fer: Don't know. You need to check. It should present itself as VID:PID 0x71b:0x3201 22.29.54 # https://copy.com/2vxUhpfNVQFl 22.30.00 # i have 3203 22.30.08 # but 22.30.22 # that is in normal mode, so not when service partition is opened. 22.30.30 # see screenshot 22.31.11 # in rkdfu mode you don't get any drive 22.31.16 # ah 22.31.38 # any idea how to send the scsi command from windows? 22.31.56 # and how to proceed further? 22.32.12 # and does the binary overwrite the original firmware? 22.32.33 # You can force this mode by shorting data pins of nand chip with some metal object and turning on in this state. This causes flash read fault and brings you rom rk dfu mode. 22.32.56 # W00fer: sorry, I have 0 experience with windows 22.33.17 # hmmm 22.33.23 # the scsi command sounds better 22.33.38 # than opening a glued device 22.34.29 # If scsi command works than good for you. The procedure with nand I outlined is bullet proof. 22.34.40 # where is it? 22.34.45 # the command? 22.34.59 # i can try it from ubuntu 22.35.26 # http://git.rockbox.org/?p=rockbox.git;a=tree;f=utils/rk27utils/rkusbtool;h=ea7ba95a4fd42292ab050cc5bb20befc08ce6e59;hb=cc64d9eb3bb74e987093d59c6a4af4b7bc76076d 22.35.42 # that is a .c file 22.35.53 # how am i supposed to run that? 22.35.53 Quit bluebrother (Read error: Connection reset by peer) 22.36.17 # you need to compile 22.36.27 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 22.36.36 # yeah without knowledge of the whole toolchain 22.36.41 # never compiled software myself 22.38.44 Quit fs-bluebot (Ping timeout: 248 seconds) 22.39.51 Join thomj [0] (~thomj@2001:840:4243:3::100) 22.39.54 # Hi all: I have a Sansa Fuze+ that used to run Rockbox fine. But now it won't boot, either Rockbox or the original firmware (VolDown+Power). Just plugging in USB shows "Boot version: 1.0" on the screen and I can access storage just fine, and I can still save files which remain after unplugging-replugging (so it's not the dead internal storage problem). Reset (hold Power for 20sec) doesn't do anything. Recovery mode (VolUp+USB plugin 22.39.57 Nick thomj is now known as preglow (~thomj@2001:840:4243:3::100) 22.40.05 Join fs-bluebot [0] (~fs-bluebo@g224236191.adsl.alicedsl.de) 22.41.08 # <[Saint]> BobJonkman1: have you tried simply copying an unmodified firmware image to the root of starage and then ejecting? 22.41.15 # <[Saint]> *storage, even 22.41.36 # [Saint]: "starage" sound like it would be a cool thing to have 22.42.10 # [Saint]: Haven't tried copying manually, but there's a firmware.sb file in the root now. Hang on, will try again. 22.44.26 # <[Saint]> Using a unix-like OS, it is possible to force the decive into a low level SoC based recovery mode and pass a firmware image to it to execute. 22.44.27 # kugel: i don't quite understand what you're trying to do wrt speex 22.44.54 # W00fer: The upgrade process, outlined in manual you emailed me, uses special type of .rkw file. It is not the same as the BASE.RKW you have in SYSTEM folder on hidden drive. 22.44.59 # <[Saint]> From there, you /may/ be able to restore the device using its own repair/format capabilities in the OF. 22.45.11 # <[Saint]> see: http://www.rockbox.org/wiki/SansaFuzePlus#Recovery_mode 22.45.25 # <[Saint]> But someone will almost certainly have to walk you through it. 22.45.27 # BobJonkman1: is the battery completely discharged ? Maybe that why you can't boot 22.45.31 # [Saint]: Nope, the Fuze+ still won't boot with a fresh firmware.sb in root 22.45.42 # <[Saint]> BobJonkman1: pamaury is the man to talk to here. 22.45.49 # let's say I have a voice clip of 1.5K. I want to copy the first 1K to a spare area and decode from that. Then I want to copy the rest (0.5K) to the same spare area and deocde the remaining bytes 22.45.49 # try to plug the device in OF USB mode (hold volume down when plugging usb) 22.45.52 # <[Saint]> You;re very lucky he's here. :) 22.45.53 # preglow: ^ 22.46.07 # pamaury: Possible. It's been plugged in for hours, so possibly the battery isn't holding a charge 22.46.09 # ah you are the same guy of the e-mail 22.46.14 # didn't knew that 22.46.25 # BobJonkman1: bootloader 1.0 of Rockbox doesn't charge, only version 2.0 does 22.46.28 # kugel: sure, sounds sane :> 22.46.42 # yup that .rkw file is the one I don't have 22.46.43 # you should probably update to the newest bootloader 22.47.12 # preglow: I don't know how to do that properly :) 22.47.29 # any way I can assemble a .rkw from that hidden partition myself? 22.47.41 # with the naive implementation the decoder errors out on the second chunk 22.47.42 # kugel: well, as long as your buffer size is always larger than the minimum speex frame size, it should just be a matter of copying and decoding 22.47.56 # if i remember correctly, we do variable size frames by default, tho 22.48.07 # pamaury: Hmmm... How to charge it then? Use an external power adapter instead of the computer's USB? 22.48.31 # <[Saint]> [10:45:51] try to plug the device in OF USB mode (hold volume down when plugging usb) 22.48.55 # W00fer: In theory yes. I didn't try however. I am not aware of any tool to do this so you would need to write one first. 22.48.57 # wodz: hmmm, I somehow read that as h300, not hd300. Feel free to delete my comment (I can't right now) 22.49.17 # <[Saint]> Oh...holy crap. 22.49.22 # <[Saint]> I did the same thing. 22.49.27 # <[Saint]> wodz: gevaerts: ^ 22.49.35 # <[Saint]> (sorry wodz :'( ) 22.49.40 # pamaury, [Saint]: Plugged in with VolDown, nothing happens. 22.49.53 # gevaerts: you read it right BUT the mode works the same. 22.50.10 # gevaerts: Its just how coldfire bootloaders work 22.50.15 # <[Saint]> Ah. 22.50.25 # wodz do you have any experience with the rk27 sdk? 22.50.27 # preglow: what I'm seeing is that the decoder attempts to deocde the whole buffer regardless of frame/packet size (1024 bytes) and sets the overflow bit 22.50.31 # since it is available 22.50.33 # pamaury [Saint]: Ah, a few seconds later it shows the "Boot version: 1.0" screen, and connects as storage device 22.50.57 # BobJonkman1: are you running Linux or Windows ? 22.51.02 # reading some docs I think that's because we don't insert terminators into the talk clips so it must decode the clip at once? 22.51.07 # pamaury: Linux 22.51.13 # <[Saint]> I totally forgot about the 1.0 bootloader not charging 22.51.23 # kugel: maybe it does :> i think mike sevakis had to deal with most of that side of things 22.51.25 # * [Saint] should probably stick to the devices he knows well 22.51.26 # W00fer: I know it quite well but never attempted to actually build the code. I use it as a reference only (as a last resort) 22.52.02 # hmm 22.52.07 # BobJonkman1: 32 or 64-bit ? 22.52.09 # kugel: sorry i don't really know anything relevant about it 22.52.18 # doesn't bring me much further after all 22.52.25 # still my question holds 22.52.30 # if i can set it in DFU moe 22.52.31 # mode 22.52.43 # am I able to safely run the rockbox code? 22.53.09 # there are reports that rk27 platform is "virtually unbrickable" 22.53.17 # pamaury: 64bit (Linux Mint 16, Petra, uname -a is "Linux zelazny 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux" 22.53.23 # but I don't want to take the chance 22.54.05 # W00fer: You can try with the tool I pointed you out. You can safely run code in dfu mode. The platform is unbrickable in the sense that the worst you can end up is rom dfu mode :-) 22.54.29 # BobJonkman1: download https://www.dropbox.com/s/rc2gl8t3lm67gwd/sbloader_64 and https://www.dropbox.com/s/ya6k3sz46chhstd/firmware_fuzep_rb_v2.sb 22.55.07 # yeah 22.55.17 # but how to get out of dfu mode? 22.55.22 # when you are done, plug the device in recovery mode (by holding volume up), then (probably as root) run ./sbloader_64 22.55.43 # if it works correctly, it should show rockbox USB bootloader mode, but showing "2.0" instead and it should charge 22.55.45 # preglow: :'( 22.55.54 # W00fer: But the truth is that THERE IS NO ROCKBOX for your device. You would need to write drivers. 22.56.18 # hmm 22.56.24 # W00fer: If you are lucky this will be tiny part probably but still. 22.56.32 # i suspected otherwise since the changelog 22.56.39 # and the status page 22.56.45 # with 100% greens 22.56.49 # which status page? 22.56.53 *** Saving seen data "./dancer.seen" 22.56.58 # rk27generic? 22.57.18 # kugel: where does the code decoding out of the audio buffer live these days? :) 22.57.29 # this is for reference design (RM970 and clones) 22.57.40 # http://www.rockbox.org/wiki/Rockchip27xxPort 22.58.11 # maybe mine is a ramos clone 22.58.12 # after all 22.58.24 # rm970 is not touchscreen 22.58.25 # preglow: in talk.c it calls mp3_play_data(). this passes the (entire) voice clip to voice_thread.c 22.59.00 # touchscreen is just an add on 22.59.05 # extra chip 22.59.10 # W00fer: You could reuse most of the code but I bet there are device specific part. 22.59.14 # in voice_thread.c it initializes the deocder and sets the speex buffer to the one from mp3_play_data() 22.59.32 # is there any active rk27 development? 23.00.11 # pamaury: OK, downloaded. 23.00.25 # W00fer: That depends what you mean by active. I play with the hardware from time to time but my spare time is limited. 23.00.45 # BobJonkman1: then run it as I explained 23.00.54 # are you the only developer for that platform? 23.01.02 Join saratoga_ [0] (123e1c65@gateway/web/freenode/ip.18.62.28.101) 23.01.09 # W00fer: basically yes. 23.01.16 # pamaury: OK, here goes. Thanx in advance! 23.01.34 # kugel: code seems to assume all the data is contained in the bit buffer 23.01.51 # too bad, i would like to contribute as much as I can 23.01.52 # W00fer: if you're not into c programming, basically none of this matters to you since you won't be able to port anything to your device 23.01.58 # kugel: which is assumed to be one contiguous area of mem 23.02.16 # and what can I do to change this assumption? 23.02.24 # saratoga_ thanks for the comment 23.02.25 # but 23.02.32 # kugel: havin a look now 23.02.39 # i'm just more than dumb end user 23.03.15 # i would like to contribute, sure I'll understand that you can't learn me do C in a day. But I know people that can, but don't have any rockbox experience 23.04.01 # i'd probably start with something much simpler if you want to learn c 23.04.16 # starts with, what can i do to help. 23.04.18 # most people learn to walk before they run 23.04.33 # i'm not talking coding, thank you 23.04.41 # W00fer: The port for your device is doable but YOU need to take care of porting. I can share my knowledge about the platform but I don't have time to hack yet another random player. 23.05.15 # there is no "generic" rk27 build that i can execute to test and report results? 23.05.22 # no 23.05.39 # well, there is but I doubt it will work 23.05.44 # why 23.05.55 # because of touchscreen okay 23.05.59 # W00fer: i think you're a little confused about how porting works 23.06.00 # preglow: cool 23.06.09 # you have to reverse engineer your device, then write device drivers for it 23.06.15 # i know that 23.06.21 # theres nothing to test until you've done that 23.06.29 Quit toehser (Read error: Connection reset by peer) 23.06.43 # but since the platform is the same, and drivers are there (although from rm970) 23.06.48 # preglow: as I said, I'm assuming we must include more terminators at encoding to make it not having to decode the whole buffer at once 23.06.57 # but I may be wrong, I know nothing about speex 23.07.18 Quit n1s (Quit: Ex-Chat) 23.07.23 # naw, shouldn't need to do anything at encode 23.07.30 # pamaury: OK, result: "Cannot probe transfer size". I've read the sbloader --help; is transfer size the filesize of the .sb file? 23.07.59 # no, did you run it as root ? 23.08.03 # but yeah, it might not work, but we didn't test it. Let's just say i think that rk27xxport on rockbox wiki then needs a name change to rm970port 23.08.13 # not to confuse people with rk27xx platform players 23.08.13 # pamaury: Yes, from a root shell 23.08.18 # preglow: when I pass only part of the buffer the decoder returns with 0 at some point with the overflow bit set 23.08.28 # and bits.charPtr is set to the last byte 23.08.32 # hum, then try to specify the transfer size: it should be 1024 23.08.34 # as it only works on that specific player 23.08.42 # iirc the option is "-x 1024" 23.08.54 # W00fer: The rk27xx part is universal (more or less) but then there are 1000000 ways to hook up additional hardware. Different ways to connect buttons, different lcd controllers, etc 23.08.59 # pamaury: OK, will do. 23.09.43 # so why is it being reported then as universal platform, as only 1 player will work and most probably none of the other players 23.10.07 # and never will 23.10.11 # pamaury: Aha! Response: "Status passed", and the device rebooted. Still says "Boot version: 1.0" tho 23.12.36 # W00fer: Sorry but you don't understand the basics of electronic design then. You start from generic (reference) design and add your stuff. This port is for this generic part. Some manufacturers do pure generics, some change software only and some change something in design. 23.13.06 # even rk SDK has many conditionals 23.13.18 # BobJonkman1: hum, ok if you don't mind, I will prepare a special firmware to recover from very low battery for tomorrow and we can retry tomorrow ? 23.13.23 # yeah and i'm enthusiastic to see if from that reference design i can generate some information for you to develop further :) 23.13.32 # pamaury: That would be wonderful. 23.13.40 # and i do understand that you don't want to develop for some random player 23.13.49 # W00fer: No you can't. 23.14.18 # W00fer: like i said before, if you're not going to do the work yourself, don't worry about this and just go buy a supported player 23.14.26 # i already have 23.14.57 # i just expected a bit more support for someone who is trying to help 23.15.02 # W00fer: Don't take it personal, maybe your player is nice and dandy but I don't have interest in spending my time on this. 23.15.26 # W00fer: if you're not working on it, then you should not expect anything at all 23.15.27 # W00fer: I can share the knowledge which will save you something like few hundred hours of work that is 23.16.34 # if you are not actively developing the platform, and i will have to do device specific porting on my own its a waste of time (even for my friends who do know C). 23.16.58 # i was just curious about the active state of development 23.17.06 # talking to you is a waste of time, send whoever you know that wants to work on this in 23.17.16 # then let them discuss what they need to know 23.17.40 # why are you even participating sara, didn't knew i asked 23.18.08 # thanks wodz 23.18.10 # W00fer: you are rude, to speak mildly 23.19.30 # hmm i asked quite politely, just some simple questions. 23.19.57 # W00fer: No, you insist to do the work for you. That is quite different 23.20.38 # i just wanted to know how to execute rockbox and send the reports, i never asked for a full player support. 23.20.54 # or end user ready version 23.21.06 # W00fer: didn't we say that you can't ? what is the problem 23.21.25 # There is NO enduser version for your player. I stated this already 23.21.44 # it sounds weird to me that nobody is interested in debugging information for their own benefit 23.21.48 # but that's my mistake then 23.22.02 # sorry bout that 23.22.02 # there is no information you can provide that would be beneficial 23.22.07 # W00fer: And I said how to run custom code. 23.22.16 # ok 23.23.20 # good luck then 23.23.36 # anyway, this argument is pointless 23.23.42 # lets get back on topic 23.24.08 # thanks for the help saratoga 23.24.12 # appreciate it 23.25.13 Part W00fer 23.26.10 # <[Saint]> Some people... 23.27.11 # <[Saint]> Do we somehow come off to the public as being professional or something? 23.27.37 Quit krabador (Quit: Sto andando via) 23.27.51 # <[Saint]> Errr...I mean, do you think somehow people are getting the impression that this is anything more than a community hobby project? 23.27.55 # Wow... And here I'm swept off my feet by the level of support *I'm* getting. 23.28.35 # <[Saint]> BobJonkman1: We do try and make it painless where possible. 23.28.52 # <[Saint]> Its a LOT easier when those seeking support are calm and rational, though. 23.28.53 # [Saint]: The guy was simply clueless how embedded developments works 23.29.00 # its that awkward problem of needing to know a lot before you can even comprehend how little you really know about software 23.29.18 # [Saint]: I've always been exceptionally impressed by the support provided on FAIF projects 23.29.36 # people think that since they can use a computer that they're most of the way to being an experienced embedded engineer 23.29.46 # and get upset when told otherwise 23.29.49 Join krabador [0] (~krabador@unaffiliated/krabador) 23.30.55 # <[Saint]> The thing that seemed to push that user over the edge was the suggestion that no one is actually interested in doing this work for him/her and that if s/he wanted it to happen, they were the best candidate for the job. 23.31.06 # saratoga_: well they *are* on the way to be experienced embedded engineer. It just something like 1000 hours of learning 23.31.20 # <[Saint]> Hehehehe 23.31.41 # A few months ago I was on the #ownCloud channel asking for support, preparing to make a SoftwareFreedomDay presentation on ownCloud. I got to speak to a developer in that channel too, who was actually just a few km from where I was. He actually came to my SFD presentation and helped present! Try to get that level of involvement from commercial projects 23.32.19 Join W00fer [0] (~W00fer@a80-101-149-96.adsl.xs4all.nl) 23.32.20 # <[Saint]> BobJonkman1: A huge part of it revolves around people doing what they love. 23.32.29 # too bad u guys talk about me when i was away 23.32.32 # <[Saint]> It isn't hard to be passionate about a topic you enjoy. 23.32.33 # * BobJonkman1 wishes he had better coding chops to make contributions 23.32.35 # but i can read logs 23.32.45 # Short question; the bootloader linked for creative zen on the wiki page is betav2, i see a link to betav3 on the forum thread, should i be updating or was that only something to test a specific issue? 23.32.50 # I didn't know much about C or electronics not speaking about asm and reverse engineering when I started 23.32.51 # <[Saint]> W00fer: Its not a secret club 23.33.36 # nope it isn't 23.33.42 # <[Saint]> Soukyuu: Dvelopment thread trumps wiki. 23.33.57 # [Saint], thanks 23.34.23 # i started out knowing how to design processors in verilog and built a few MIPS ones, but still read assembly at a rate of like 3 opcodes a minute after like 8 years on this project 23.34.38 # is the hierarchy irc > forum thread > wiki? 23.35.17 # usually whatever is newer 23.35.24 # <[Saint]> IRC is where we would prefer you to seek support/advice, but the forums are no less accurate or less likely to get a response. 23.35.42 Quit pamaury (Ping timeout: 260 seconds) 23.36.01 # <[Saint]> The wiki can be potentially misleading, as there's no obligation for anyone to keep the information contained within current. 23.36.14 # yeah i experienced that 23.36.15 # now 23.36.26 # <[Saint]> So there can be ancient contradictory documentation mixed amongst the latest current documentation. 23.36.51 # if it was accurate, i would have never asked this question as i thought that it was accurate for the platform. 23.36.58 # but fine with that 23.37.19 # kugel: yeah, the decoder pretty much requires the entire frame to be present in the bit buffer 23.37.40 # <[Saint]> There's nothing misleading about the Rockchip page(s) I'm aware of. 23.37.55 # kugel: i can't really tell you too much about this, and i doubt mike could either 23.38.15 # i found the decoder returns quite a few times before the clip is fully decoded, so it does actually decode in chunks 23.38.19 # kugel: you basically have to keep feeding the decoder a bit buffer of more than the biggest frame speex does, then keep track of how much it eats 23.38.29 # W00fer: It is accurate for the platform. There are drivers for timers, lcdif, pll, cache and whatsever. That doesn't mean you can take arbitrary player build around rk27xx SoC and expect everything to be supported 23.38.29 # kugel: oh sure 23.38.46 # kugel: what we do now is pass it all the data at once, and feed it the same bit buffer until speex itself says it's done 23.38.55 # kugel: speex itself knows perfectly well how big its frames are 23.39.00 # then it should display that it is a platform, different than a port 23.39.10 # for end user hardware 23.39.13 # it is in the same list 23.39.37 # kugel: the main speex.c codec we have does this, but it has some ogg framing that hides the raw details 23.39.44 # in my opinion 23.40.07 # kugel: but it too has chunks of multiple speex frames delimited at the proper boundaries 23.40.16 # W00fer: no offense, but you're not qualified to have an opinion here 23.40.23 # yea I looked at that, the main codec seems to have more information that the voice clips offer 23.40.39 # i do take it as an offense, sorry bout that 23.40.51 # kugel: ah, there's one main gotcha here 23.40.59 # kugel: we never flush the bit buffer to byte align it 23.41.12 # <[Saint]> The Rockchip wiki is very clear about it being for the SoC itself. 23.41.31 # <[Saint]> It doesn't state it will "Just WOrk" on any arbitrary rk device. 23.41.58 # saint, where is that it only is for that soc? 23.42.18 # must have misread then 23.42.52 # <[Saint]> That page is only documenting the SoC variants. 23.43.02 # <[Saint]> No other hardware is mentioned. 23.43.24 # http://www.rockbox.org/wiki/TargetStatus#New_Platforms_Currently_Under_Development 23.43.29 # <[Saint]> It is possible to run arbirary code on these devices, but that is very far from a fully supported port. 23.43.34 # yeah 23.44.25 # and i asked thus, how i can run that arbitrary code to experiment :) 23.44.39 # <[Saint]> And wodz told you. 23.45.20 # preglow: how can you do that? 23.45.23 # kugel: that can be worked around without breaking the files we already have, but it's going to mean you have to manually bit align every time you reorder the buffer of data you give speex 23.46.05 # <[Saint]> Ah, slight apology, I thought you were referring to the Rockchip SoC wiki page. 23.46.08 # couldnt you stash bits.bitPtr and re-use the last byte? 23.46.14 # <[Saint]> ...but that doesn;t really change much. 23.46.30 # yeah 23.46.31 # kugel: probably, yeah 23.46.35 # it states players 23.46.37 # pandora, onda 23.46.45 # kugel: yeah, almost certainly 23.46.45 # ipod 23.47.24 # <[Saint]> iPo...huh? There's no Rockchip iPods. 23.47.35 # target list 23.48.41 # but okay, back on topic 23.49.01 # kugel: so, basically either learn how to read speex frame sizes to ensure you have a whole one, or base yourself on the max frame size, so you know speex will never run out of data 23.49.20 # kugel: and fixup the bit buffer when you notice you haven't got enough anymore 23.49.37 # copying from pcmbuf 23.52.31 # well, the maximum frame size seems easy: I read it's 20ms of audio, so as a simplification the max. frame size is 20ms of pcm data 23.52.50 # yeah, but drastically less in speex form 23.53.36 # afaik, speex frames are fixed size, speex in vbr mode will choose from a list of frame sizes it can make for a given frame of pcm audio 23.53.40 # right but it's still small enough to not be a problem. I'm considering a 1K buffer which should be more than sufficient 23.53.54 # 1k is almost certainly more than you'll need, yeah 23.54.01 Quit foolsh (Read error: Connection reset by peer) 23.54.10 # I'm off now, thanks for your help 23.54.16 # no worries 23.58.25 # preglow: any interest in working on codecs these days? 23.58.38 Quit kugel (Ping timeout: 252 seconds) 23.58.42 # saratoga_: always, depends on the codec, but no time atm or for the next months 23.58.47 Join toehser [0] (~tom@Connqueror.Toms.NET) 23.58.48 # yeah same here 23.58.54 # any interest in Opus? 23.59.00 # yeah