| 00:03:02 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140205162153]) |
| 00:03:29 | * | [Saint] frowns. |
| 00:03:40 | [Saint] | How can you get a Stkov for the audio buffer? |
| 00:04:19 | * | [Saint] removes the and buffer from that sentence, as writing it severaltimes failed rather dramatically |
| 00:08:00 | [Saint] | No RaaAoA on my phone is kinda heartbreaking. Google Music is so...meh. |
| 00:08:14 | | Join fs-bluebot [0] (~fs-bluebo@g224236041.adsl.alicedsl.de) |
| 00:08:32 | JdGordon | [Saint]: any way to do gdb to it? |
| 00:08:41 | JdGordon | have you tried in the sim? |
| 00:09:01 | | Quit rela (Read error: Connection reset by peer) |
| 00:09:14 | [Saint] | I didn't think an SDL build could accurately represent RaaAoA. |
| 00:09:25 | [Saint] | (so, no, I didn't try as yet) |
| 00:09:50 | JdGordon | you dont know if it is the JNI or warble or what code causing the problem |
| 00:10:16 | [Saint] | I would build RaaAoA myself, but apparently that is impossible these days. |
| 00:10:35 | [Saint] | My fix/kludge to get it building with a modern toolchain no longer works. |
| 00:11:01 | [Saint] | and its impossible to get the older S/NDK from a trusted source (apparently?). |
| 00:11:44 | [Saint] | JdGordon: Well...I know warble works fine, if that's any consolation. |
| 00:11:53 | [Saint] | But I don't think that's really indicative of much. |
| 00:12:48 | [Saint] | For all I know, it may be a problem with rasher's builds...but I can't really check that, as it involves way too much effort on my part to get it building here. |
| 00:13:26 | [Saint] | (and if I did get it building again with a modern S/NDK, I couldn;t rule out any problems as being introduced by said workaround) |
| 00:15:27 | [Saint] | And I can't get a map file from rasher's builds... |
| 00:15:30 | [Saint] | Gah. |
| 00:18:16 | [Saint] | I'm left to wonder if it is somehow just my problem, and it affects all my devices, or if no one uses RaaAoA anymore (at least not a modern version thereof). |
| 00:23:25 | | Quit onder` (Ping timeout: 252 seconds) |
| 00:25:17 | | Join onder` [0] (~onder@dyn-dsl-to-76-75-112-23.nexicom.net) |
| 00:31:27 | | Join onder`_ [0] (~onder@dyn-dsl-to-76-75-112-23.nexicom.net) |
| 00:31:57 | | Quit onder` (Ping timeout: 260 seconds) |
| 00:32:02 | | Nick onder`_ is now known as onder` (~onder@dyn-dsl-to-76-75-112-23.nexicom.net) |
| 00:39:00 | Strife89 | [Saint]: I think I still have some builds sitting in my Dropbox; what's your phone's resolution? |
| 00:41:39 | Strife89 | Last successful builds were made on Dec. 26. |
| 00:46:52 | | Quit ender` (Quit: Remember: A secretary isn't permanent until she's been screwed on the desk...) |
| 00:58:17 | | Join soap [0] (~soap@cpe-174-102-103-175.woh.res.rr.com) |
| 00:58:17 | | Quit soap (Changing host) |
| 00:58:17 | | Join soap [0] (~soap@rockbox/staff/soap) |
| 01:00 |
| 01:05:32 | | Quit markun (Quit: leaving) |
| 01:06:02 | *** | Saving seen data "./dancer.seen" |
| 01:10:44 | | Quit ZincAlloy (Quit: Leaving.) |
| 02:00 |
| 02:37:17 | [Saint] | Crap. Sorry Strife89, didn't see the notification. If you have 480x800 compiled it would run on all the devices I own. |
| 02:37:37 | [Saint] | I'll prod at it when I get home. |
| 02:40:24 | Strife89 | [Saint]: Yup, I have it. Here. https://www.dropbox.com/s/az1mqxva2frvr2o/ally-2013-12-26.apk |
| 02:41:12 | | Join pedro_angelo [0] (~pedro_ang@201-19-53-120.user.veloxzone.com.br) |
| 02:41:37 | [Saint] | Excellent. Thanks. |
| 03:00 |
| 03:01:53 | | Join onder`_ [0] (~onder@dyn-dsl-to-76-75-118-5.nexicom.net) |
| 03:04:43 | | Quit onder` (Ping timeout: 260 seconds) |
| 03:04:49 | | Nick onder`_ is now known as onder` (~onder@dyn-dsl-to-76-75-118-5.nexicom.net) |
| 03:06:03 | *** | Saving seen data "./dancer.seen" |
| 03:14:42 | | Join plain-user [0] (~plain-use@ppp121-45-162-235.lns20.syd6.internode.on.net) |
| 03:38:13 | | Quit Ooga_Booga (Remote host closed the connection) |
| 03:38:18 | | Join JeremyGoodwin [0] (6c14a639@gateway/web/freenode/ip.108.20.166.57) |
| 03:40:47 | | Quit JeremyGoodwin (Client Quit) |
| 03:41:34 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 04:00 |
| 04:02:32 | | Quit krabador (Quit: Sto andando via) |
| 04:27:43 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
| 04:27:43 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:27:43 | | Quit amiconn (Disconnected by services) |
| 04:27:43 | | Quit pixelma (Disconnected by services) |
| 04:27:46 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
| 04:40:11 | | Quit plain-user (Quit: Leaving) |
| 05:00 |
| 05:01:25 | | Nick DormantBrain is now known as SuperBrainAK (~andy@74.112.200.73) |
| 05:02:19 | SuperBrainAK | hey guys hows your evening/morning? |
| 05:03:32 | SuperBrainAK | i was wondering does the sansa clip zip processor have any spare I/O? |
| 05:04:12 | [Saint] | What is it you're wanting to achieve? |
| 05:05:12 | JdGordon | does the thing have headphone detection? |
| 05:05:30 | [Saint] | I believe so. |
| 05:05:37 | SuperBrainAK | idk some sort of volume knob like a continuous rotation pot or rotary encoder |
| 05:05:47 | SuperBrainAK | no it doesnt |
| 05:06:00 | SuperBrainAK | idk |
| 05:06:06 | *** | Saving seen data "./dancer.seen" |
| 05:06:08 | SuperBrainAK | i dont know |
| 05:06:15 | [Saint] | It probably does. But we may not make use of it. |
| 05:06:24 | SuperBrainAK | ah |
| 05:06:25 | SuperBrainAK | yea |
| 05:06:32 | JdGordon | saratoga on the forums says only insert which is pretty sueless |
| 05:06:44 | [Saint] | Its a very young port still and things like that tend to get neglected. |
| 05:07:28 | SuperBrainAK | well you wouldnt really need to know if the jack is detected really it doesnt have external speakers to switch to |
| 05:08:32 | JdGordon | pause on unplug.... |
| 05:08:42 | [Saint] | You could probably hijack the mic input via the dock. |
| 05:10:25 | [Saint] | But, in general, if you want to play with things like this a DAP isn't really the best candidate. |
| 05:10:49 | [Saint] | Sounds like you want to play with something you can actually sink your teeth into the hardware of. |
| 05:11:16 | [Saint] | One of the bajillion ARM dev boards out there is probably a good start. |
| 05:11:43 | [Saint] | (and you could run Rockbox on that, too :)) |
| 05:12:16 | [Saint] | Another option, I guess, if its enabled in the port, is HID. |
| 05:12:23 | | Quit pedro_angelo (Remote host closed the connection) |
| 05:16:26 | | Quit TheSeven (Disconnected by services) |
| 05:16:38 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 05:21:57 | | Quit ruskie (Quit: ...) |
| 05:30:09 | | Join uw [0] (~uw@unaffiliated/uw) |
| 05:32:43 | | Join ruskie [0] (ruskie@sourcemage/mage/ruskie) |
| 05:36:37 | | Quit Strife89 (Quit: Leaving) |
| 05:36:38 | | Join Strife1989 [0] (~Strife89@adsl-98-80-214-9.mcn.bellsouth.net) |
| 05:42:48 | | Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) |
| 05:43:05 | saratoga | IIRC the manual says it can detect an insert but not a remove |
| 05:44:00 | saratoga | i guess you could probably unsolder some of the buttons or LEDs and use that for IO |
| 05:44:07 | saratoga | a lot of them are just GPIO pins |
| 05:44:23 | [Saint] | COuld you not use the dock? |
| 05:44:37 | [Saint] | As I said earlier, perhaps hijack mic in off the dock? |
| 05:45:23 | saratoga | theres no dock on the zip |
| 05:49:58 | [Saint] | Oh. Crap. Indeed. |
| 06:00 |
| 06:10:49 | | Nick SuperBrainAK is now known as DormantBrain (~andy@74.112.200.73) |
| 06:56:29 | | Join tapiralec [0] (~alec@cpe-76-184-244-146.tx.res.rr.com) |
| 07:00 |
| 07:06:10 | *** | Saving seen data "./dancer.seen" |
| 07:43:33 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 07:51:29 | | Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) |
| 07:53:26 | | Join mortalis [0] (~kvirc@213.33.220.118) |
| 08:00 |
| 08:06:22 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
| 08:07:27 | | Quit akaWolf (Client Quit) |
| 08:10:21 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:27:23 | | Join wodz [0] (~wodz@89-75-151-160.dynamic.chello.pl) |
| 08:28:11 | wodz | Zagor: (log) I get 'remote: warning: unable to access '/root/.config/git/attributes': Permission denied' when git pull. I don't recall seeing this message before |
| 08:32:55 | wodz | pamaury: (log) http://pastie.org/8725047 when building regtools after todays git pull |
| 08:33:02 | | Quit fragilematter (Quit: Leaving.) |
| 08:43:56 | wodz | pamaury: (log) qeditor is affected also. After fixing std::vector vs std::list I get some undefined references to hwstub stuff and pretty suspicious warning http://pastie.org/8725073 |
| 08:48:14 | wodz | pamaury: (log) my bad, I forgot to build the lib. It would be great if the build system remembers about this and build libhwstub. a instead of throwing error |
| 08:51:02 | wodz | pamaury: (log) hwstub_shell also suffers from std::vector vs std::list. Cumulative patch to fix definitions http://pastie.org/8725086 |
| 08:55:14 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 09:00 |
| 09:01:15 | | Quit Strife1989 (Ping timeout: 250 seconds) |
| 09:02:12 | | Join Zagor [0] (~bjst@80.239.169.203) |
| 09:02:12 | | Quit Zagor (Changing host) |
| 09:02:12 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 09:06:14 | *** | Saving seen data "./dancer.seen" |
| 09:06:55 | | Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) |
| 09:26:05 | | Quit bertrik (Ping timeout: 245 seconds) |
| 09:28:07 | | Quit wodz (Ping timeout: 250 seconds) |
| 09:36:49 | copper | pamaury (logs): https://outpost.fr/tmp/nDI.txt |
| 09:37:33 | copper | I guess I was right to suspect the sd card |
| 09:38:06 | | Join kugel [0] (~kugel@193.174.67.16) |
| 09:38:06 | | Quit kugel (Changing host) |
| 09:38:06 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 09:51:11 | | Quit kugel (Read error: Connection reset by peer) |
| 09:59:40 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 10:00 |
| 10:04:40 | | Join kugel [0] (~kugel@193.174.67.16) |
| 10:04:40 | | Quit kugel (Changing host) |
| 10:04:40 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 10:05:32 | kugel | [Saint]: works for me (right channel this time) |
| 10:06:36 | [Saint] | Forgive me if I don't repeat my rant in here. :) |
| 10:08:14 | kugel | there are many problems on android that I cannot reproduce, and unless I get serious help I'm unable to make it any better |
| 10:08:43 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 10:09:21 | pixelma | like the app hanging after playing a few tracks for me |
| 10:09:48 | pixelma | unfortunately I haven't found a pattern yet |
| 10:10:41 | copper | pamaury: logs |
| 10:12:15 | [Saint] | pixelma: yeah, thats a fun one. |
| 10:12:48 | [Saint] | force closing several times in a row and then magically working is another good one. |
| 10:13:42 | [Saint] | Boot. Nope! Boot. Nope! Boot. Ok, I'll work now. |
| 10:14:31 | | Join stoyan [0] (~io-headqu@77.70.0.98) |
| 10:15:58 | | Quit stoyan (Client Quit) |
| 10:16:51 | pixelma | having the wrong colours in the notification dropdown (or whatever it's called) on my SE ICS phone is also a nice one I couldn't figure out yet. It's the only app I've seen so far doing this |
| 10:19:31 | | Quit tchan (Quit: WeeChat 0.4.2) |
| 10:20:37 | pixelma | though not terribly important |
| 10:21:33 | pamaury | copper: thanks, I need to go, I'll be back this afternoon to study this file |
| 10:22:41 | [Saint] | If I had the same issues with Rockbox on a DAP, it would be a lot easier to gather the motivation to do something about it. |
| 10:22:49 | copper | cool |
| 10:23:22 | [Saint] | But its difficult to think the same way about Android with so many functional alternatives. |
| 10:26:32 | | Quit pamaury (Ping timeout: 272 seconds) |
| 10:28:32 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 11:00 |
| 11:01:51 | | Join kuldeepdhaka [0] (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 11:02:17 | | Quit kuldeepdhaka (Max SendQ exceeded) |
| 11:06:17 | *** | Saving seen data "./dancer.seen" |
| 11:08:07 | kugel | [Saint]: the skin engine is not the problem |
| 11:08:19 | [Saint] | Its certainly *a* problem. |
| 11:08:24 | kugel | we could have disabled it for the time being |
| 11:08:43 | [Saint] | That was the very first step in the whole "maybe we're not thinking about this right" phase of RaaAoA. |
| 11:08:50 | kugel | our entire architecture is a bad fit for android |
| 11:09:06 | [Saint] | You won;t see me arguing there. |
| 11:11:45 | kugel | but perhaps you don't realize how bad the fit is :) |
| 11:12:40 | [Saint] | No, I do. Which is one of the reasons I'm surprised it progressed so far, and lasted as long as it did. |
| 11:13:00 | * | [Saint] notes he's using past tense and tries not to |
| 11:14:05 | [Saint] | It really is a credit to you, and all the others involved that it is as functional as it is. |
| 11:14:56 | [Saint] | I'm not trying to discredit the work, not at all. |
| 11:16:09 | [Saint] | But looking back, its easy (now) to say "What was who thinking when we thought this could work?" |
| 11:20:20 | | Quit kugel (Ping timeout: 248 seconds) |
| 11:22:00 | | Join kuldeepdhaka [0] (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 11:33:22 | | Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) |
| 11:33:32 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 11:34:44 | | Quit dfkt (Ping timeout: 248 seconds) |
| 11:55:18 | | Quit sciopat (Quit: Leaving) |
| 12:00 |
| 12:25:34 | | Join ZincAlloy [0] (~Adium@pD9EE9107.dip0.t-ipconnect.de) |
| 12:32:50 | | Quit tapiralec (Quit: Ex-Chat) |
| 12:45:06 | | Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) |
| 12:56:10 | pamaury | wodz (logs): yeah you're right, I forgot to fix some programs, the warning is normal, it's just because I compare the current version of hwstub to the reported one and since it's currently 0 the "<" chek is always false |
| 13:00 |
| 13:06:19 | *** | Saving seen data "./dancer.seen" |
| 13:14:15 | fs-bluebot | Build Server message: New build round started. Revision c35e4a4, 250 builds, 33 clients. |
| 13:15:06 | pamaury | wodz (logs): compilation should be fixed now, the undefine references in qeditor seem weird though, the qmake adds the hwstub library to the linker |
| 13:17:17 | fs-bluebot | Build Server message: Build round completed after 183 seconds. |
| 13:17:29 | pamaury | copper: I will need to send you a new build, I would not have expected the code to fail at this point and I need more debug information |
| 13:17:46 | copper | that's ok |
| 13:21:58 | | Quit ikeboy (Quit: Leaving) |
| 13:22:06 | | Join dfkt [0] (OxO29A@unaffiliated/dfkt) |
| 13:33:56 | | Quit fragilematter (Quit: Leaving.) |
| 13:36:10 | pamaury | copper: https://www.dropbox.com/s/rf06athk6c0x96n/rockbox_debug_msd_fuzep2.zip |
| 13:36:39 | | Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) |
| 13:41:49 | copper | got it |
| 13:49:47 | copper | pamaury: not sure that's going to help much: https://outpost.fr/tmp/hHG.txt |
| 13:52:16 | pamaury | ok interesting, apparently a transfer fails and the card stops responding |
| 13:52:30 | * | [Saint] wonders what's up with that link that hover-preview fails on it |
| 13:52:51 | [Saint] | all your outpost.fr links screw up hover-preview for me, actually. Hmmm. |
| 13:52:54 | pamaury | copper: I will need more debug :) |
| 13:59:16 | copper | hehe |
| 13:59:33 | copper | [Saint]: using embed.ly? |
| 14:00 |
| 14:00:33 | [Saint] | Using....whatever quassel uses to do hover-preview, which seems to work for everything else but your links. |
| 14:01:04 | [Saint] | (vastly offtopic, just something I noticed since you brutishly forced me into clicking a link :P) |
| 14:03:16 | | Join wodz [0] (~wodz@89-75-151-160.dynamic.chello.pl) |
| 14:03:42 | pamaury | copper: https://www.dropbox.com/s/rzacco8lerlcxkl/rockbox_debug_msd_fuzep3.zip |
| 14:04:10 | copper | [Saint]: can't see why, I'm not doing anything special in that .txt link |
| 14:15:34 | copper | pamaury: trying to run into the bug, no luck yet |
| 14:23:43 | copper | ah, finally |
| 14:25:01 | copper | pamaury: https://outpost.fr/tmp/Z89.txt |
| 14:26:56 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 14:43:25 | | Join amayer [0] (~amayer@173.189.251.62) |
| 14:48:51 | | Join krabador [0] (~darkarch@host131-142-dynamic.59-82-r.retail.telecomitalia.it) |
| 14:48:51 | | Quit krabador (Changing host) |
| 14:48:51 | | Join krabador [0] (~darkarch@unaffiliated/krabador) |
| 14:49:09 | | Quit krabador (Client Quit) |
| 14:49:51 | | Join krabador [0] (~darkarch@unaffiliated/krabador) |
| 14:50:00 | | Quit krabador (Client Quit) |
| 14:50:29 | | Join krabador [0] (~darkarch@unaffiliated/krabador) |
| 14:53:36 | | Quit wodz (Ping timeout: 260 seconds) |
| 15:00 |
| 15:03:10 | | Quit fragilematter (Quit: Leaving.) |
| 15:06:15 | pamaury | copper: so the problem is that the card times out and does not answer anymore |
| 15:06:22 | *** | Saving seen data "./dancer.seen" |
| 15:06:26 | pamaury | this looks like a bug of the card to me |
| 15:07:05 | copper | jesus |
| 15:07:07 | copper | it's brand new |
| 15:07:20 | copper | and a replacement for my other fucked up card |
| 15:07:41 | copper | and I checked, SanDisk didn't send me back the same card |
| 15:07:45 | copper | different serials |
| 15:08:11 | copper | pamaury: if it's the card, I should run into the bug with a Clip+ too, right? |
| 15:08:45 | pamaury | not necessarily, the drivers are slightly different, it could be a timing issue |
| 15:09:38 | copper | ok, first I'm going to try a build from when kugel fixed the theme bugs |
| 15:13:00 | pamaury | what is puzzling is why 64GB cards seems to more prone to this issue |
| 15:14:19 | copper | they do? |
| 15:14:41 | pamaury | metaphys bricked a 64GB card recently on the fuze+ |
| 15:15:12 | | Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) |
| 15:15:33 | copper | I guess that's what happened to my previous card too |
| 15:16:07 | pamaury | but bricked card is a firmware bug, except by frying it you cannot brick a card with software commands |
| 15:16:28 | copper | well I've had many USB flash drive controllers get bricked, too |
| 15:17:01 | copper | those things seem flaky as shit |
| 15:17:48 | pamaury | this issue though looks different, it may be a problem with the driver but what ?! |
| 15:18:07 | copper | I'm trying to run into the bug with the kugel build right now |
| 15:18:28 | pamaury | what is the kugel build ? |
| 15:19:39 | copper | short hand for "a build from when kugel fixed the theme bugs" |
| 15:19:48 | copper | 193911a to be precise |
| 15:20:05 | copper | because I don't remember having that problem back then, but it could just be a coincidence |
| 15:20:35 | copper | if I can't manage to run into the bug with that build, then maybe there's something on the Rockbox side |
| 15:21:37 | copper | ok, nope |
| 15:21:42 | copper | just ran into the bug |
| 15:22:14 | copper | ok let's try the Clip+ now |
| 15:23:26 | | Quit fragilematter (Quit: Leaving.) |
| 15:24:08 | * | [Saint] doesn't understand the concept of software "bricking" sdcards. |
| 15:24:22 | [Saint] | Surely its a firmware issue if it is possible for this to happen. |
| 15:24:31 | [Saint] | ...or an overvoltage, or something. |
| 15:25:06 | [Saint] | The latter can definitely do it, I know that, be we should certainly be safe there. |
| 15:25:39 | [Saint] | In my mind, for this to happen in some way, even if it is triggered by a driver fault, the card has to be defective in some way. |
| 15:26:08 | [Saint] | If it wasn't, surely the worst that could happen is a trashed filesystem? |
| 15:27:08 | pamaury | maybe you could brick it by sending some vendor specific commands that do nasty undocumented stuff |
| 15:27:24 | [Saint] | Hmmm. Right. |
| 15:27:36 | pamaury | but since the SD bus is CRC'd, that's very unlikely |
| 15:27:41 | copper | I'm sick of those flimsy flash devices |
| 15:28:04 | [Saint] | The flash is likely fine. |
| 15:28:10 | [Saint] | This seems like afirmware issue. |
| 15:28:16 | [Saint] | *a firmware |
| 15:28:29 | copper | I'm talking about the devices as a whole |
| 15:28:39 | [Saint] | AH. Sorry. Too literal. |
| 15:29:17 | copper | I've never stopped having problems with those, ever since I bought my first USB flash drive in, what, 2000 or something? |
| 15:30:06 | pamaury | it's because the problem is far from trivial |
| 15:30:34 | pamaury | the illusion that you can use a NAND flash as a block device is fundamentally flawed from the start |
| 15:31:29 | pamaury | that's why flash file systems exist |
| 15:32:10 | [Saint] | Yeah, this ^ |
| 15:32:16 | pamaury | on big devices like SSD you can probably compensate by adding some RAM which makes it easier for the firmware but on microSD stuff everything has to be horribly small |
| 15:33:29 | copper | god, that toy is so damn small (the Clip+) |
| 15:35:13 | pamaury | any news about the clip sport ? |
| 15:36:07 | copper | http://www.sandisk.com/about-sandisk/press-room/press-releases/2014/sandisk-announces-new-mp3-player-designed-for-athletes-and-fitness-enthusiasts/ |
| 15:36:20 | [Saint] | I'm slightly suspicious (and possibly hopeful) of it being a recycled model in a different case. |
| 15:36:37 | [Saint] | (with some firmware additions to make it seem justifiable) |
| 15:37:48 | ZincAlloy | you've seen the pics, right? http://www.head-fi.org/t/697524/clip-zip-sport-16gb/45 |
| 15:38:07 | pamaury | yeah but the inside ? |
| 15:38:22 | ZincAlloy | I guess someone here has to buy one ^^ |
| 15:38:28 | pamaury | has nobody tried to reach a recovery mode for example ? |
| 15:38:54 | [Saint] | No one I know of has one. |
| 15:42:19 | | Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) |
| 15:46:27 | ZincAlloy | I think it's rather save to assume that they upgraded the hardware for better battery life. |
| 15:50:24 | copper | Clip+ refuses to crap out |
| 15:50:42 | PurlingNayuki_ | Anyone else notices the warning from lib/unwarminder/backtrace.c? |
| 15:51:14 | | Nick PurlingNayuki_ is now known as PurlingNayuki (uid20107@gateway/web/irccloud.com/x-pywbegcdrzcjusjv) |
| 15:51:54 | PurlingNayuki | lib/unwarminder/backtrace.c:111:15: warning: variable 'r' set but not used [-Wunused-but-set-variable] |
| 15:51:54 | PurlingNayuki | UnwResult r; |
| 15:52:22 | PurlingNayuki | But I checked that file and see variable r is used lines below definition |
| 15:52:56 | gevaerts | PurlingNayuki: it's not used |
| 15:53:04 | gevaerts | It's set, but nothing reads it |
| 15:53:17 | gevaerts | Which compiler are you using? |
| 15:53:31 | PurlingNayuki | r = UnwindStart(pcAddr, spAddr, &cliCallbacks, (void *)line); |
| 15:53:35 | PurlingNayuki | Isn't this use r? |
| 15:53:51 | gevaerts | That's the "set" part of "set but not used" |
| 15:54:26 | PurlingNayuki | I'm using arm-linux-androideabi-gcc 4.8 from Android NDK |
| 15:54:45 | gevaerts | Right. That's the sort of thing that's not unexpected with newer compilers |
| 15:55:37 | pamaury | note that the build you produce could be faulty because of using an unsupported compilers |
| 15:56:12 | n1s | PurlingNayuki: if it wan't set at all you'd get a "defined but not used" warning |
| 15:56:21 | gevaerts | pamaury: did we ever actually specify an ndk version to use? |
| 15:56:38 | * | [Saint] assumes this isn;t for Android |
| 15:56:39 | PurlingNayuki | Despite of the warning it does work on real Android targets. |
| 15:57:22 | pamaury | ah yeah for android I guess it's fine |
| 15:57:54 | PurlingNayuki | That's a library for arm, but not for arm that runs Android right? |
| 15:58:58 | pamaury | I think the unwinder is compiled on Android too |
| 15:59:24 | PurlingNayuki | And there's also another warning in apps/menus/main_menu.c, line 251 |
| 15:59:36 | pamaury | but I don't have rockboxed android device so I don't know if it's actually used |
| 16:00 |
| 16:00:17 | * | [Saint] is curious, if this is indeed for Android, what S/NDK version is being used, and what trickery was needed to compile Rockbox for Android thereon. |
| 16:00:39 | [Saint] | The tools we rely on haven't been present for several revisions. |
| 16:02:06 | [Saint] | I managed to get it to compile a few revisions ago, but my kludge for that stopped working a while back. |
| 16:02:54 | [Saint] | PurlingNayuki: ^ |
| 16:10:02 | PurlingNayuki | [Saint]: Are you talking about apkbuilder? |
| 16:10:25 | [Saint] | among others. |
| 16:11:00 | PurlingNayuki | As a simple solution, I added it back to my modified source but we should really use aapt. |
| 16:11:05 | [Saint] | replacing apkbuilder alone doesn't get the job done. |
| 16:11:28 | [Saint] | It /may/ work, if you updated the S/NDK in place from prior revisions, and they are left over. |
| 16:11:47 | [Saint] | From a clean installation, I have had exactly zero success. |
| 16:12:29 | PurlingNayuki | I can't remember what I did but anyway I got this compiled. |
| 16:13:01 | PurlingNayuki | Bump the SDK version in android.make may help. |
| 16:13:29 | [Saint] | I suspect that the tools apkbuilder itself calls were left over in your SDK installation. |
| 16:13:37 | [Saint] | I can't think of another way it would work. |
| 16:14:11 | PurlingNayuki | I've said that I added it back to my source. |
| 16:15:14 | PurlingNayuki | I should write to use aapt but I'm a lazy guy. |
| 16:16:23 | [Saint] | I know you added apkbuilder back, but that itself relies on tools that either moved and/or are no longer present. |
| 16:16:50 | [Saint] | So at the least I would expect some linking magic. It would be nice to know, that's all. |
| 16:17:29 | PurlingNayuki | And thanks to your notice I remember I set links for those missing files. |
| 16:18:34 | [Saint] | Aha. Right. |
| 16:18:49 | PurlingNayuki | That should be enough for a instant fix. |
| 16:19:17 | PurlingNayuki | Anyway we should turn to aapt right? |
| 16:19:50 | [Saint] | I sincerely doubt anyone would prevent you from doing so. |
| 16:20:42 | PurlingNayuki | That's it.;-) |
| 16:20:44 | [Saint] | I'll have another go at setting this up again, I couldn't get it to work even following my own directions last time. :) |
| 16:22:04 | PurlingNayuki | I will try this maybe in one week ir two |
| 16:22:05 | [Saint] | A small part of me doesn't want to get it working. As then I'll want to start fixing things that annoy me, and I'll get all depressed about doing what I feel is heading in the wrong direction. |
| 16:22:13 | | Quit n1s (Quit: Ex-Chat) |
| 16:23:01 | [Saint] | I used to believe very strongly that RaaA on Android had a future. Not so much anymore. |
| 16:23:54 | [Saint] | I love it to bits for its features, but the approach is wrong in so many ways. Well beyond my technical ability to fix. |
| 16:24:08 | ZincAlloy | becaue nobody has an mp3 player anymore. everbody needs to have the latest, greatest device? :D |
| 16:24:20 | [Saint] | No. |
| 16:24:31 | [Saint] | Because bringing our UI with us was a terrible idea. |
| 16:25:01 | ZincAlloy | yeah. I can hardly imagine how that would work well |
| 16:25:07 | [Saint] | (note: the views of [Saint] are not wholly representative of the Rockbox project :)) |
| 16:25:25 | PurlingNayuki | A one for iPhone may have an equal future, if there is :D |
| 16:26:14 | [Saint] | Is that a cryptic way of saying "no future"? :) |
| 16:26:53 | [Saint] | I don't quite believe that. As a playback library, I believe Rockbox has a future on many devices and platforms. |
| 16:27:07 | [Saint] | well, I would like to. |
| 16:28:56 | [Saint] | Its depressing being passionate about something when you don't have the technical ability nor the time to correct the flaws you see. |
| 16:28:58 | PurlingNayuki | Actually I released several versions of RaaA and the strongest voice from thousands of users is, it's wonderful, excluding its UI |
| 16:30:00 | [Saint] | I agree completely. |
| 16:30:31 | [Saint] | Which is why I see Rockbox as having a future on Android as a playback library open for other applications to use. |
| 16:31:09 | PurlingNayuki | I have taken measures to solve that, temporarily. |
| 16:31:32 | PurlingNayuki | That's pre-packed themes. |
| 16:31:37 | [Saint] | In the past, I believed very strongly that we could overcome the issues with the UI. But rotation and resolution agnostic UIs proved to be all but impossible. |
| 16:31:55 | [Saint] | A binary per resolution would never fly in the wild. |
| 16:32:59 | [Saint] | (were it to ever be a "product") |
| 16:33:04 | PurlingNayuki | I agree this. |
| 16:33:44 | PurlingNayuki | I have a simple solution to resolution too. |
| 16:34:03 | [Saint] | Oh? |
| 16:34:11 | PurlingNayuki | it's far from perfect but at least usable. |
| 16:35:02 | [Saint] | The only way I know of is making sure the theme is the same size or smaller than target resolution. |
| 16:35:57 | [Saint] | But then it gets pinned to 0,0 and you get a black border to the side and bottom. |
| 16:36:18 | PurlingNayuki | Simply zoom the outputs to the resolution as the devices' |
| 16:37:32 | [Saint] | Ah, cute. |
| 16:38:52 | [Saint] | Now, in later versions of Android, we hae other fun things to worry about. |
| 16:39:06 | PurlingNayuki | And we have got this working |
| 16:39:10 | [Saint] | Like dynamic navigation soft keys and status bar. |
| 16:39:35 | [Saint] | *we have |
| 16:39:50 | PurlingNayuki | Oops, another we |
| 16:40:35 | [Saint] | Errrr, sorry. I was correcting myself. |
| 16:42:15 | PurlingNayuki | The best is to adapt to Android NATIVE UI using jni at present |
| 16:46:18 | PurlingNayuki | And we can drop theme support for the very first versions |
| 16:48:40 | PurlingNayuki | Yeah I know that's one of the main features but most users want a usable one, not a fully-customizable one. |
| 16:51:36 | | Join scorche|1h [0] (~scorche@squisch.net) |
| 16:51:36 | | Quit scorche|1h (Changing host) |
| 16:51:36 | | Join scorche|1h [0] (~scorche@rockbox/administrator/scorche) |
| 16:52:36 | Zagor | I recall suggesting percent positioning quite a long time ago... :-) |
| 16:53:08 | Zagor | of course, talking is easy |
| 16:53:51 | ZincAlloy | scaleable graphics would be useful for this |
| 16:55:57 | [Saint] | Zagor: i recall you doing more than suggesting it. |
| 16:56:22 | Zagor | yeah, right. I did some work too. never finished though. |
| 16:56:40 | | Quit ruskie (*.net *.split) |
| 16:56:40 | | Quit fs-bluebot (*.net *.split) |
| 16:56:41 | | Quit rbert (*.net *.split) |
| 16:56:41 | | Quit Provel (*.net *.split) |
| 16:56:41 | | Quit scorche|sh (*.net *.split) |
| 16:57:01 | | Join Provel [0] (~Provel@97-88-171-31.dhcp.stls.mo.charter.com) |
| 16:57:18 | [Saint] | I seem to recall you trying and then some form of "crap, this is harder than it should be". |
| 16:57:50 | [Saint] | And then lots of discussion around native ui. |
| 16:58:47 | Zagor | I don't remember exactly. but I knew it was never going to be a perfect solution, so I can imagine that put a damper on my enthusiasm for spending long hours fixing it. |
| 16:59:02 | [Saint] | right. |
| 16:59:38 | Zagor | a rockbox lib and native UI is basically the only sane way |
| 17:00 |
| 17:00:17 | [Saint] | I regret not seeing that earlier on SOOO much. |
| 17:01:04 | Zagor | :) |
| 17:01:10 | | Quit Zagor (Quit: Clint excited) |
| 17:01:25 | | Quit fragilematter (Quit: Leaving.) |
| 17:01:43 | [Saint] | I feel partly responsible for it. I was adamant that the skin engine could be made to work around the areas we fell down in. |
| 17:02:14 | | Join ruskie [0] (ruskie@sourcemage/mage/ruskie) |
| 17:02:22 | | Join rbert [0] (~robin@141.70.11.4) |
| 17:02:57 | [Saint] | What a fool hindsight can make one seem. :-/ |
| 17:04:49 | | Quit krabador (Quit: It's Time To Take The Time!!!) |
| 17:06:23 | *** | Saving seen data "./dancer.seen" |
| 17:11:00 | | Join krabador [0] (~darkarch@unaffiliated/krabador) |
| 17:44:50 | | Join wodz [0] (~wodz@89-75-151-160.dynamic.chello.pl) |
| 17:45:17 | wodz | pamaury: with your fixes commited I get this: http://pastie.org/8726658 |
| 17:48:13 | pamaury | wodz: did you compile the hwstub library in utils/hwstub/lib ? |
| 17:53:01 | | Quit uw (Quit: Leaving) |
| 17:53:48 | | Quit mortalis (Ping timeout: 250 seconds) |
| 18:00 |
| 18:30:42 | saratoga | i see that the new clip model is somewhat available in various stores around the US, has anyone gotten a hold of one and opened it yet? |
| 18:31:19 | saratoga | i'm betting on it being imx233 fwiw |
| 18:31:38 | ZincAlloy | I bet you'd win that bet |
| 18:32:26 | saratoga | with any luck we can delay pamaury's phd even more |
| 18:32:35 | ZincAlloy | LOL |
| 18:39:22 | ZincAlloy | as you guys are using the imx far more efficiently than sandisk you might get an incredible battery life out of the clip sport.. |
| 18:39:52 | [Saint] | Gah. |
| 18:40:13 | [Saint] | The manual entry for the WPS context menu is...somewhat lacking. |
| 18:40:31 | [Saint] | "Like the context menu for the File Browser, the WPS Context Menu allows you quick access to some often used functions." :-/ |
| 18:40:46 | ZincAlloy | oh wel |
| 18:40:47 | ZincAlloy | l |
| 18:40:50 | [Saint] | Technically correct, rather bland. |
| 18:41:05 | [Saint] | Yay. .tex for me when I wake up. |
| 18:41:14 | [Saint] | (note: not yay at all) |
| 18:45:10 | ZincAlloy | seems like the clip sport updates its database way faster than the clip zip: http://anythingbutipod.com/forum/showthread.php?t=73402&page=6 |
| 18:52:07 | | Quit krabador (Remote host closed the connection) |
| 18:54:43 | | Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) |
| 18:54:43 | | Quit bertrik (Changing host) |
| 18:54:43 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 19:00 |
| 19:05:14 | | Quit scorche|1h (Ping timeout: 272 seconds) |
| 19:05:56 | | Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) |
| 19:06:24 | toehser1 | 128x128 - is the screen bigger than the zip's 96x96, or just finer resolution? |
| 19:06:26 | *** | Saving seen data "./dancer.seen" |
| 19:06:33 | ZincAlloy | it's bigger |
| 19:06:46 | | Join krabador [0] (~darkarch@unaffiliated/krabador) |
| 19:07:21 | ZincAlloy | 1.44" |
| 19:07:53 | toehser1 | Zip was, 1.1" I think? |
| 19:08:01 | ZincAlloy | I think so, yes. |
| 19:08:52 | ZincAlloy | according to the reviewer, the clip sport's screen is much better than the clip zip's. that's good news.. |
| 19:09:49 | ZincAlloy | stiffer buttons and tighter headphone jack, too. but his clip zip might just be worn out.. |
| 19:13:22 | toehser1 | Here's a mock-up someone did of Rockbox running on it: http://cdn.head-fi.org/f/f2/500x1000px-LL-f2dc6edf_sansa_clip_generations.jpeg |
| 19:14:29 | ZincAlloy | I prefer the cabbie themed model: http://oi62.tinypic.com/mm78rb.jpg |
| 19:21:44 | | Join lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr) |
| 19:25:54 | | Nick whiskers75 is now known as whisk (~whiskers7@unaffiliated/whiskers75) |
| 19:26:02 | | Nick whisk is now known as whiskers75 (~whiskers7@unaffiliated/whiskers75) |
| 19:27:34 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 19:45:08 | | Quit pamaury (Ping timeout: 272 seconds) |
| 19:51:13 | bertrik | looking forward to hacking a clip zip sport |
| 19:52:00 | ZincAlloy | It sure looks like a big improvement over the clip zip other than the stop button issue.. |
| 19:52:06 | | Quit wodz (Ping timeout: 260 seconds) |
| 19:53:44 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 19:55:31 | [Saint] | Given the stated information, I'm not sure how you can come to that conclusion. |
| 19:55:45 | [Saint] | All we know is it has a feature we probably won't us, and a pretty case. |
| 19:55:48 | [Saint] | *use |
| 19:55:56 | lebellium | bertrik: Clip Sport* :P |
| 19:59:24 | ZincAlloy | they even dropped the Sansa name |
| 20:00 |
| 20:01:01 | toehser1 | What feature we won't use? Certainly we would use the 128x128/1.44" screen real estate, and the faster processor, and the doubled storage :) |
| 20:01:13 | bertrik | oh, saw it still mentioned on amazon. Is it already up on the sandisk web page? |
| 20:01:20 | ZincAlloy | yes |
| 20:01:29 | ZincAlloy | and they have a forum for it, too |
| 20:01:35 | lebellium | ZincAlloy: they already dropped it before. On the recent Clip+ it's written "sandisk" instead of "sansa" on the front. And on the Clip Zip it's also written Sandisk |
| 20:01:57 | toehser1 | Best Buy has the 4 & 8 ones in the US on sale now, 16s are showing up on eBay from Israel. |
| 20:02:14 | ZincAlloy | but the clip zip still has the sansa logo on the back |
| 20:02:22 | bertrik | Ok, I see it on the sandisk page. I hope it's bascially a zip with an upgraded screen, for easy porting |
| 20:03:28 | toehser1 | The back says sandisk. It is bigger than the zip, not just the screen. |
| 20:04:01 | ZincAlloy | interesting. according to the specs it was pretty much the same size |
| 20:04:55 | toehser1 | look at the pics in page 4 of this thread: http://www.head-fi.org/t/697524/clip-zip-sport-16gb/45 |
| 20:05:56 | ZincAlloy | so is a clip+ the same size as a clip zip? |
| 20:06:59 | [Saint] | toehser1: ....errrr...the SoC has been confirmed? |
| 20:07:40 | [Saint] | re: what feature won't we use? - that crappy FM gym/fitness center local radio crap. |
| 20:08:13 | toehser1 | Oh - right. I so much "won't use" that, that I had already tuned it out (so to speak). |
| 20:08:36 | [Saint] | Care to comment on your apparent inside knowledge of the SoC? |
| 20:08:48 | ZincAlloy | would that be any different from a regular fm tuner? |
| 20:09:03 | [Saint] | ZincAlloy: Not at all. :) |
| 20:09:16 | bertrik | I vaguely remember unlocking the diagnostic mode on my zip by pressing *all* buttons at once during boot, I'll try that again. Maybe if someone does that on the sport, we can get some extra info about the internals. |
| 20:09:20 | [Saint] | Doesn't stop them advertising it as a feature. |
| 20:09:42 | ZincAlloy | sounds like good marketing to me |
| 20:11:43 | * | [Saint] puts the SoC statement down to assuming that probablies are definitlelies |
| 20:11:57 | [Saint] | (but feel free to hit me with a source if there is one) |
| 20:13:07 | [Saint] | I'm willing to believe that the mold hasn't been broken from the other past variants and the HW is very much what we'll expect it to be |
| 20:14:17 | bertrik | does anyone know what the current firmware version of the clip sport is? |
| 20:14:46 | lebellium | no |
| 20:14:56 | toehser1 | I'm extrapolating from the user who found that db operations were much faster than on previous ones, but that may be because they've fundamentally changed their database implementation, not because of the hardware, based on other comments. |
| 20:14:58 | lebellium | we know nothing about it because usual users don't care about anything |
| 20:15:10 | lebellium | devs are obliged to buy it :) |
| 20:18:17 | toehser1 | clip zip is slightly bigger than clip plus, but not nearly as much bigger as the sport seems to be. I haven't found the dimensions posted, but there is the side-by-side with a clip+ picture, and there are side-by-sides of course between zip and plus. |
| 20:18:57 | [Saint] | toehser1: such extrapolation is flawed |
| 20:19:07 | [Saint] | It could simply boil down a a faster NAND. |
| 20:19:30 | | Quit rbert (Quit: Verlassend) |
| 20:19:34 | [Saint] | Its likely, indeed, but I'd like to avoid pure speculation. |
| 20:20:35 | ZincAlloy | we can only speculate as long as noone bothers to buy a player ^^ |
| 20:21:23 | [Saint] | No, we know two things at least. It has a "pretty" case and an FM non-feature. |
| 20:21:26 | [Saint] | ;) |
| 20:21:46 | ZincAlloy | and a larger screen. and better battery life. |
| 20:22:10 | [Saint] | Well, we know the stated battery life. |
| 20:22:19 | [Saint] | Runtime has yet to be seen in the wild. |
| 20:22:30 | ZincAlloy | and since the player is physically bigger than the clip zip that can mean two things: it uses a more efficient chip or it has a bigger battery. |
| 20:22:58 | ZincAlloy | I assume it's somewhat realistic |
| 20:23:15 | [Saint] | How does bigger player == more efficient SoC? |
| 20:23:30 | soap | bigger screen |
| 20:23:32 | ZincAlloy | it means a bigger battery could fit in |
| 20:24:57 | [Saint] | The battery part is understandable. But I don't quite get how bigger player directly equates to a more efficient SoC. |
| 20:25:28 | ZincAlloy | it doesn't. more efficient SoC is a possible explanation for the better battery life |
| 20:25:46 | [Saint] | I'm almost willing to bet cash money on it being an SoC we've seen in this range before. |
| 20:26:04 | ZincAlloy | That's very likely |
| 20:26:18 | toehser1 | I hope so - that makes a port much easier, doesn't it? |
| 20:26:23 | ZincAlloy | considering their history |
| 20:26:28 | [Saint] | Much so. |
| 20:27:03 | [Saint] | It would be fun to disassemble and see what lessons, if any, they learned from Rockbox. |
| 20:27:09 | saratoga | my guess is its probably a fuze+ in a different package, imx is so cheap no sense designing something new |
| 20:27:21 | [Saint] | saratoga: That's what I'm guessing too |
| 20:27:26 | ZincAlloy | considering the firmware reviews: probably not much at all |
| 20:27:32 | [Saint] | Just a pretty case on the same old same old. |
| 20:27:52 | ZincAlloy | which is not a bad thing |
| 20:28:02 | saratoga | retail price of the whole SOC is like 4 dollars |
| 20:28:10 | * | [Saint] nods |
| 20:28:11 | saratoga | order 10 million and its probably way less |
| 20:28:39 | [Saint] | They possibly even fabricate themselves? |
| 20:28:45 | [Saint] | Big enough to. |
| 20:29:32 | [Saint] | I wouldn't be terribly surprised if they had holdings in a fabrication plant. |
| 20:30:34 | saratoga | freescale would handle that |
| 20:32:19 | saratoga | parts like this are fabbed on some ancient process familiar to the vendor to keep costs low, porting it to some modern fab would be cost prohibitive |
| 20:32:52 | saratoga | plus the analog bits are not friendly to porting |
| 20:36:06 | [Saint] | Oh. Yeah. Right. Indeed, if they aren't making their own flash controllers for sd, its unlikely they're fabricating SoCs. |
| 20:36:25 | [Saint] | I have no idea why I didn't think of that. |
| 20:38:05 | [Saint] | (partial backstory: like almost everyone else they seem to be doing little more than repackaging Toshiba controllers) |
| 20:38:05 | ZincAlloy | funny that they haven't bothered to include microsdxc support |
| 20:38:31 | saratoga | looking on line its done in 90 nm lp, so probably some old motorola fab left over from the mid-2000s |
| 20:38:53 | saratoga | although thats quite a bit newer than AMS, so probably why battery life is better |
| 20:39:05 | [Saint] | 90nm?!? |
| 20:39:12 | [Saint] | Slightly larger than I expected. |
| 20:39:41 | [Saint] | I guess these don;t really need such fine processing, though. |
| 20:40:29 | saratoga | AMS was 130 nm |
| 20:40:36 | saratoga | most PP was 180 nm |
| 20:40:46 | saratoga | theres a reason these things cost a few dollars each |
| 20:40:51 | [Saint] | I knew PP was huge (not really, for its time). |
| 20:41:13 | * | whiskers75 hugs [Saint] |
| 20:41:13 | saratoga | its funny to see these ancient processors on semi-modern fab processes though |
| 20:41:21 | saratoga | ARM9E was designed on 250 nm I think |
| 20:41:23 | [Saint] | But the other two I find a little surprising |
| 20:41:32 | saratoga | arm7tdmi isn't much younger then CMOS itself |
| 20:41:52 | * | [Saint] looks at his faithful iPod |
| 20:42:16 | * | whiskers75 looks at his faithful Sansa Clip+ |
| 20:43:06 | saratoga | "Samsung microSD cards contain an ARM7TDMI controller with 128 KB of code." |
| 20:43:08 | saratoga | haha |
| 20:43:18 | saratoga | so they have the 7tdmi at least running on 45 nm, maybe newer |
| 20:43:46 | whiskers75 | hug a developer day! |
| 20:43:53 | * | whiskers75 hugs saratoga |
| 20:45:14 | [Saint] | A little offtopic, but I wonder if we will ever actually see 2TB SDXC in our lifetime, or ever. |
| 20:45:35 | [Saint] | (for instance, if a newer format comes along and kills uSD) |
| 20:45:49 | [Saint] | However unlikely that may be. |
| 20:45:54 | saratoga | probably in SDXC |
| 20:46:02 | saratoga | maybe not microSDXC |
| 20:46:17 | [Saint] | whoops. right. forgot a u |
| 20:46:33 | saratoga | i don't see SDXC going away anytime in the next decade |
| 20:46:56 | [Saint] | I'm surprised SD has lasted as long as it has. |
| 20:47:08 | saratoga | i'm not sure if it will be possible to put 2TB in a uSDXC card using CMOS flash cells |
| 20:47:15 | [Saint] | Hell...some things use CF still. |
| 20:48:41 | [Saint] | I suppose we'll have to look semi-seriously into exFAT support in the near-ish future, assume the project survives and maintains relevance. |
| 20:48:50 | [Saint] | *assuming |
| 20:48:52 | saratoga | i don't think it would be very hard to do |
| 20:49:02 | saratoga | the exfat libraries i saw looked fairly simple |
| 20:49:27 | saratoga | theres not a huge need at the moment though since reformatting to fat32 is pretty easy |
| 20:49:39 | [Saint] | Hah. |
| 20:49:45 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
| 20:49:52 | [Saint] | I managed to completely miss exFAT going GPL |
| 20:50:26 | saratoga | i think theres at least 2 different libraries |
| 20:50:46 | saratoga | i think samsung open sourced one as well |
| 20:51:15 | [Saint] | Yeah, hence my prior comment. I found it surprising. |
| 20:51:42 | [Saint] | Last time I looked there was a very function RE'd implemenation. |
| 20:51:42 | saratoga | its a simple file format, so reverse engineering it was probably very easy |
| 20:51:51 | saratoga | compared to say a FTL |
| 20:52:35 | | Join wodz [0] (~wodz@89-75-151-160.dynamic.chello.pl) |
| 20:53:00 | | Quit krabador (Quit: It's Time To Take The Time!!!) |
| 20:54:49 | | Join krabador [0] (~darkarch@unaffiliated/krabador) |
| 20:55:05 | [Saint] | Oh. Hmmmm. |
| 20:55:22 | [Saint] | I'm somewhat confused about the legality of the use of exFAT. |
| 20:55:38 | | Part LinusN |
| 20:55:40 | [Saint] | It seems it is "open", but still very much protected. IANAL. |
| 20:56:29 | Galois | the code is GPL but may still be patent-encumbered in some jurisdictions, notably the USA |
| 20:56:35 | [Saint] | As in, they gave us the /ability/ to use it, but not the /right/ to. |
| 20:56:50 | [Saint] | Basically what Galois just said, yeah. |
| 20:57:03 | [Saint] | TL;DR: Stupid US patent laws shitting on things |
| 20:57:07 | Galois | similar to mp3 a few years ago, before the mp3 patents expired |
| 20:58:01 | [Saint] | Didn't the US extend the term of utility patents fairly recently? |
| 20:58:14 | [Saint] | (recent in terms of "not a massive amount of time ago) |
| 20:58:19 | Galois | no? it's 20 years from date of filing |
| 20:58:25 | Galois | the last extension was in like 1992 or something |
| 20:58:57 | [Saint] | Oh geez. How do I remember 1995? |
| 20:59:05 | Galois | you're right, 1995 |
| 20:59:07 | [Saint] | Man... |
| 20:59:14 | Galois | "For applications filed before June 8, 1995, the term is either 17 years from the issue date or 20 years from the earliest claimed domestic priority date, whichever is longer." |
| 20:59:22 | | Quit chrisjj (Ping timeout: 245 seconds) |
| 20:59:31 | [Saint] | Where'd you dig that up? |
| 20:59:39 | Galois | wikipedia https://en.wikipedia.org/wiki/United_States_patent_law |
| 20:59:49 | [Saint] | Ah. Thanks. |
| 20:59:54 | Galois | copyright terms were extended in 1998, by 20 years, to protect mickey mouse |
| 21:00 |
| 21:00:12 | | Quit saratoga (Ping timeout: 245 seconds) |
| 21:00:14 | Galois | count on another extension of copyright terms in 2018, when mickey mouse comes under threat again |
| 21:00:57 | [Saint] | Getting wildly offtopic, but if Mickey Mouse is still relevant enough to need that protection in 2018, I fear I may kill myself. |
| 21:01:46 | ZincAlloy | why does mickey mouse need copyright protection at all? wouldn't the appearance be trademarked? |
| 21:02:13 | Galois | the early films are, of course, copyrighted. Disney doesn't want you copying those exact movies. |
| 21:06:27 | *** | Saving seen data "./dancer.seen" |
| 21:06:35 | | Quit rela (Read error: Connection reset by peer) |
| 21:10:01 | | Quit y4n (Quit: AMIGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAHAHAAAAAAAAAAAAHAHAAA) |
| 21:10:11 | | Join LinusN [0] (linus@giant.haxx.se) |
| 21:14:45 | [Saint] | ZincAlloy: or the stripped down version " 'cos, USA". |
| 21:15:40 | | Quit shamus (Ping timeout: 245 seconds) |
| 21:15:54 | [Saint] | Land of the free, harley davidson, bald eagles, and the violently litigious. |
| 21:16:05 | | Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) |
| 21:20:38 | | Join pedro_angelo [0] (~pedro_ang@201-19-53-120.user.veloxzone.com.br) |
| 22:00 |
| 22:01:53 | | Quit [Saint] (Remote host closed the connection) |
| 22:04:02 | | Join [Saint] [0] (~saint@rockbox/staff/saint) |
| 22:24:43 | | Quit ender` (Quit: Documentation is like sex: when it's good, it's very good, and when it's bad it's still better than nothing.) |
| 22:28:38 | wodz | pamaury: (log) Yes, hwstub/lib was not compiled and this was my complaint about build system. Anyway recent qeditor crashes when attempting to connect with older hwstub. I didn't try with recent hwstub yet. |
| 22:31:25 | | Quit amayer (Quit: Leaving) |
| 22:31:38 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 22:31:50 | | Quit amayer (Remote host closed the connection) |
| 22:34:02 | | Join LittleAnon [0] (~smuxi@g138199.upc-g.chello.nl) |
| 22:34:10 | LittleAnon | yes, here I am again. |
| 22:36:16 | LittleAnon | my sansa clip doesnt seem to want to read what I have on my sd card! I thought it would do it automaticly, ive rebooted a few times and used the Initiliaze + update now setting a few time, and waited for hours while I assumed it was doing that in the background, but it STILL doesnt read it and I have no indication that it actually did something |
| 22:36:21 | LittleAnon | so what do I do? |
| 22:37:02 | wodz | In which file sits database code? |
| 22:39:46 | LittleAnon | What do you mean? |
| 22:39:48 | | Quit kuldeepdhaka (Ping timeout: 250 seconds) |
| 22:41:14 | | Quit fyre^OS (Quit: quit) |
| 22:42:10 | wodz | LittleAnon: This question wasn't directed to you. |
| 22:45:27 | | Quit wodz (Quit: Leaving) |
| 22:48:29 | | Quit bluebrother (Disconnected by services) |
| 22:48:34 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 22:54:04 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 22:59:43 | pamaury | wodz (logs): can you trace back the crash of hwstub lib ? |
| 23:00 |
| 23:00:20 | pamaury | the newer version certainly won't work with older hwstub since I changed the protocol but it shouldn't crash |
| 23:00:21 | | Quit myndzi (Ping timeout: 265 seconds) |
| 23:02:09 | | Join myndzi [0] (myndzi@2600:3c00::f03c:91ff:fedf:3d4e) |
| 23:03:04 | | Quit LittleAnon (Remote host closed the connection) |
| 23:03:24 | [Saint] | LittleAnon: My first though would be to check that you haven't excluded this path from database scanning. |
| 23:04:16 | [Saint] | *first thought |
| 23:06:28 | *** | Saving seen data "./dancer.seen" |
| 23:28:16 | | Quit bertrik (Read error: Connection reset by peer) |
| 23:28:23 | | Quit pamaury (Read error: Operation timed out) |
| 23:30:00 | | Join fs-bluebot [0] (~fs-bluebo@g231121243.adsl.alicedsl.de) |
| 23:30:14 | | Quit pedro_angelo (Remote host closed the connection) |
icon identifies that the person is a core developer (has commit access).