| 00:10:13 | | Join dconrad [0] (~dconrad@208.38.228.38) |
| 00:15:16 | | Quit dconrad (Ping timeout: 276 seconds) |
| 00:27:23 | | Join munkis [0] (~mendel_mu@2600:4041:5ac9:a100:b225:aaff:fe5e:10eb) |
| 00:37:24 | *** | Saving seen data "./dancer.seen" |
| 00:46:11 | | Join skrzyp [0] (skrzyp@irc.skrzyp.net) |
| 00:48:08 | | Join dconrad [0] (~dconrad@208.38.228.38) |
| 00:50:43 | skrzyp | Question: If I get an iPod Video (5.5th gen) with iFlash Quad, is it actually possible to get the 4x1TB microSD configuration to work with Rockbox as 4TB storage? On regular iPodOS, it caps on 2TB, but I'd like to know if that's the actual OS issue or hardware controller cannot address (i know about the LBA limits on 6gen) |
| 00:52:06 | skrzyp | On the other half, maybe there's some other (newer) Rockbox target which can hold up such large amounts of storage (>=2TB), has a good battery life and sounds nice? Doesn't need to be small at all. |
| 00:53:00 | | Quit dconrad (Ping timeout: 260 seconds) |
| 01:00 |
| 01:22:16 | | Quit othello7 (Ping timeout: 252 seconds) |
| 01:22:24 | | Join drew` [0] (~drew@user/drew) |
| 01:22:59 | | Quit drew (Ping timeout: 252 seconds) |
| 01:23:08 | | Nick drew` is now known as drew (~drew@user/drew) |
| 01:36:45 | | Join dconrad [0] (~dconrad@208.38.228.38) |
| 01:40:58 | | Quit dconrad (Ping timeout: 252 seconds) |
| 02:00 |
| 02:05:42 | | Quit _bilgus (Remote host closed the connection) |
| 02:06:22 | | Join _bilgus [0] (~bilgus@syn-184-057-182-233.res.spectrum.com) |
| 02:08:06 | | Quit chorc (Ping timeout: 252 seconds) |
| 02:09:33 | | Quit vup (Remote host closed the connection) |
| 02:09:45 | | Join chorc [0] (~chorc@user/chorc) |
| 02:09:51 | | Quit Pokey (Read error: Connection reset by peer) |
| 02:10:45 | | Join Pokey [0] (~pokey@spikeyCactus/hoosky) |
| 02:10:47 | | Join vup [0] (~~~~@46.101.193.235) |
| 02:23:54 | | Join JanC_ [0] (~janc@user/janc) |
| 02:23:55 | | Quit JanC (Killed (tungsten.libera.chat (Nickname regained by services))) |
| 02:23:55 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 02:25:21 | | Join dconrad [0] (~dconrad@208.38.228.38) |
| 02:29:50 | | Quit dconrad (Ping timeout: 260 seconds) |
| 02:37:27 | *** | Saving seen data "./dancer.seen" |
| 02:40:09 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 02:40:40 | | Quit thanosengine (Ping timeout: 252 seconds) |
| 02:47:46 | Xogium | skrzyp: personally I'd avoid quad flash adapter |
| 02:48:26 | Xogium | if even one card out of the 4 you'd have in there is starting to fail, your device will start to brick itself and fall apart |
| 02:48:42 | Xogium | as in one single card failing is enough to make the whole stuff unusable |
| 02:49:24 | Xogium | good luck opening up your ipod to figure which one is failing |
| 02:58:12 | | Join lebellium [0] (~lebellium@2a01cb0405d03a004070cdf0d3f7e170.ipv6.abo.wanadoo.fr) |
| 03:00 |
| 03:09:42 | skrzyp | Xogium: makes sense, however I actually just want to mirror a library on my NAS onto these cards overnight via USB, so I don't care if the data gets lost |
| 03:10:41 | skrzyp | but I've seen some smaller dual adapters in the meantime |
| 03:10:54 | skrzyp | anyways, I still think about alternatives, if there are any |
| 03:13:56 | | Join dconrad [0] (~dconrad@208.38.228.38) |
| 03:18:29 | | Quit dconrad (Ping timeout: 252 seconds) |
| 03:28:50 | | Quit othello7 (Ping timeout: 248 seconds) |
| 03:48:23 | | Join dconrad [0] (~dconrad@208.38.228.38) |
| 03:52:40 | | Quit dconrad (Ping timeout: 244 seconds) |
| 04:00 |
| 04:02:02 | | Join JanC_ [0] (~janc@user/janc) |
| 04:02:02 | | Nick JanC is now known as Guest9166 (~janc@user/janc) |
| 04:02:02 | | Quit Guest9166 (Killed (erbium.libera.chat (Nickname regained by services))) |
| 04:02:02 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 04:36:50 | | Join dconrad [0] (~dconrad@208.38.228.38) |
| 04:37:28 | *** | Saving seen data "./dancer.seen" |
| 04:41:22 | | Quit dconrad (Ping timeout: 252 seconds) |
| 04:53:17 | CH23 | Xogium the same can be said from __any__ type of storage though. In my experience µSD cards for these purposes are quite good |
| 05:00 |
| 05:04:18 | | Quit jacobk (Ping timeout: 248 seconds) |
| 05:05:01 | | Join jacobk [0] (~quassel@47-186-65-73.dlls.tx.frontiernet.net) |
| 05:09:18 | | Join dconrad [0] (~dconrad@208.38.228.38) |
| 05:14:21 | | Quit dconrad (Ping timeout: 276 seconds) |
| 05:57:54 | | Join dconrad [0] (~dconrad@208.38.228.38) |
| 06:00 |
| 06:02:34 | | Quit dconrad (Ping timeout: 260 seconds) |
| 06:14:08 | | Quit PSparky|Ryzen7 (Quit: Leaving) |
| 06:24:16 | | Join JanC_ [0] (~janc@user/janc) |
| 06:24:16 | | Nick JanC is now known as Guest6705 (~janc@user/janc) |
| 06:24:16 | | Quit Guest6705 (Killed (tantalum.libera.chat (Nickname regained by services))) |
| 06:24:16 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 06:37:30 | *** | Saving seen data "./dancer.seen" |
| 06:46:38 | | Join dconrad [0] (~dconrad@208.38.228.38) |
| 06:51:46 | | Quit dconrad (Ping timeout: 276 seconds) |
| 07:00 |
| 07:10:22 | | Join dconrad [0] (~dconrad@208.38.228.38) |
| 07:24:13 | | Quit dconrad () |
| 08:00 |
| 08:37:34 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:17:30 | _bilgus | I'd add at first.. |
| 09:19:49 | CH23 | how much writing does rockbox do by default? |
| 09:20:11 | _bilgus | for instance my dash cam cards all start getting flaky after about a year or two my 256 gb for my DAP did the same its still working as a 64 gb card for now and that took several years |
| 09:21:11 | _bilgus | but yeah rb its self does some writing but I think writing new tracks to be the major wear |
| 09:23:15 | _bilgus | figure settings, resume info and the playlist control file to be the main writes |
| 09:36:35 | speachy | skrzyp: multiple problems: the iflash SD adapters don't implement >32bit addressing, in violation of the ATA spec. (what's one more violation..) so you're limited to 2TiB, period. |
| 09:37:19 | speachy | secondly, 2TiB is still the limitation of MBR partitioning. We do support GPT but due to how the ipod loads its firmware off of the drive, I'm not sure if it's even possible to craft a hybrid MBR+GPT arrangement that will still be bootable. |
| 09:37:47 | speachy | (if you could find a >2TB SATA SSD that would physically fit, we could test this out) |
| 09:39:37 | speachy | also, wrt the multi-SD adapters, lose one card, you will probably lose the entire filesystem. (look up RAID-0 for an explanation) |
| 09:40:30 | CH23 | yeah the ipod can still boot as long as the first µSD is accessible, but your data's gone |
| 09:40:31 | speachy | In theory, any of our (originally) HDD-based devices (microdrive/CF counts) should support full LBA48, including >2TiB. |
| 09:42:43 | speachy | but whether or not their OEM bootloaders will still successfully boot with GPT is anyone's guess. If they are entirely booted using _our_ code (IIRC the iriver devices, ipod6g/7g (maybe), and possibly others) then it's theoreitically possible but you'll lose the ability to go back to the OF entirely. |
| 09:42:54 | speachy | (without re-flashing anyway) |
| 09:44:09 | speachy | once >2TiB SD cards become available on the market (for non-ludicrous pricing) it will be worth adding proper SDUC support into rockbox, at which point any SD-capable rockbox device should be able to use that space. |
| 09:44:42 | speachy | (the same caveat applies wrt the stock/manufacturer firmware −− boot into it, your card will probably get trashed) |
| 09:45:31 | speachy | However. We're still limited to FAT32, so no more than 2TiB per partition. But you can have more than one partition. |
| 09:47:15 | speachy | correction −− any _native port_ with an SD slot. It is highly unlikely that any of the hosted ports will ever see support for SDUC as that requires kernel changes and nobody has ever published their kernel sources. |
| 09:47:55 | | Join thanosengine [0] (~thanos@user/thanosengine) |
| 09:47:59 | speachy | exFAT is still on the long-term wishlist, but it's a major undertaking. |
| 09:49:51 | speachy | (and adding exFAT will make some of our bootloaders too large to fit, so those platforms will be unable to boot off of exFAT-formatted partitions. |
| 09:50:18 | speachy | tl;dr: welcome to teh reality of shoehorning modern capabilities into ~20-year-old platforms. |
| 09:52:44 | CH23 | personally i'm a big fan of keeping the old things going into the modern age. I'm cheating on rockbox a bit by also growing a MiniDisc collection, which with a modern web interface I can easily write to. |
| 09:53:18 | speachy | "why doesn't a 20-year-old ipod offer the same flexibility and responsiveness as a modern smartphone" |
| 09:53:55 | speachy | "why do my 100K track libraries cause the database to be very slow?" |
| 09:54:05 | CH23 | lol |
| 09:54:26 | CH23 | but speachy i really need to have 5 months of music on me at all times! |
| 09:54:35 | speachy | "why does my battery life suck and the UI get unresponsive when I'm trying to play back 8-channel 24-bit 192KHz FLAC files on a device that was designed to sling 128Kbps MP3 files" ? |
| 09:55:11 | speachy | (on hardware only capable of 16-bit, 48KHz stereo playback) |
| 09:56:11 | speachy | I'm also getting increasingly annoyed by questions that could literally have been solved by reading the top few google results (one of which is usually the actual manual) |
| 10:00 |
| 10:18:34 | speachy | ...and my personal favorite −− large hi-res FLAC libraries (you know, for the "quality") using hardware that was far from audiophile quality when it was new, on open-ear headphones or earbuds. bonus ponts if playback is via bluetooth |
| 10:19:40 | speachy | (ffs, when you can hear noise when the SD card is being accessed or the screen is active, you might as well just use good 'ol mp3...) |
| 10:37:35 | *** | No seen item changed, no save performed. |
| 10:38:53 | _bilgus | well I guess herein lies the other issue with unlimited RAM and Moores law. Most of these people are probably too young to remember a time before 1-4 gb of RAM |
| 10:41:24 | speachy | kids these days, I swear... :D |
| 10:42:12 | speachy | (I do find it disappointing that if not for the ErosQ, 20-year-old ipods would remain the most easily obtainable (and capable) devices we run on..) |
| 10:42:59 | speachy | I'm pleasantly amazed they're still cranking them out (and iterating on the design) |
| 10:49:21 | _bilgus | I've been pleasantly surprised by the hifi walker still hope to see amachronics device |
| 10:50:05 | speachy | most of my spare time these days is spent racing to get stuff done outside before it gets too hot. |
| 10:51:46 | _bilgus | mine this last two weeks is rushing to clear gutters and storm drains come and swamp various family members homes and or mitigating the damage before it actual becomes an issue in one case |
| 10:52:07 | speachy | I want to take his current port and adapt it to the STM32H747i-DISCO dev board I have |
| 10:52:14 | _bilgus | monsoon season I guess |
| 10:52:54 | speachy | and use that to work on some of the generic stuff thatn eeds doing (ie peripheral drivers) |
| 10:57:04 | speachy | the current geopolitical insanity can't have been good for BOM of the echo1. |
| 10:59:28 | speachy | _bilgus: to change the subject, do you have any thoughts on effectively making rbutil GPLv3? (ie by integrating that native 7zip library) |
| 10:59:32 | Xogium | my first computer had 128 mb of ram if I recall :D |
| 10:59:52 | speachy | mine was an Atari 800XL with 64KB. :D |
| 11:00 |
| 11:00:05 | Xogium | XD |
| 11:01:26 | Xogium | first computer had both windows xp and 98 installed on it, for whatever reason. With a screen reader installed in windows 98 only |
| 11:01:29 | Xogium | I never understood |
| 11:01:59 | speachy | I think my first PC was an XT clone with 640K and a Hercules MDA adapter. (Though thanks to some bad RAM chips I think only about ~512K was usable) |
| 11:02:06 | Xogium | used it for 6 months and them BOOM went the hard drive |
| 11:03:14 | _bilgus | Well the whole issue with GPLv2 vs v3 is warble and such AFAIU I don't see why rbutil being GPL3 would mess any of that up for anyone |
| 11:03:14 | speachy | had a 20MB hard drive that became 32MB by switching from a MFM to RLL controller. |
| 11:03:29 | Xogium | :D |
| 11:03:43 | _bilgus | afterall its tied to rockbox.org in its current form anyway |
| 11:05:03 | speachy | what's the issue with warble? |
| 11:05:37 | _bilgus | none was saying the original reson to keep v2 was to keep parts of the codebase 'pure' |
| 11:06:18 | speachy | I guess I don't understand the concern in our context. |
| 11:07:01 | _bilgus | sorry I was saying in the context of plugins and codecs being separate entities |
| 11:08:29 | speachy | ...Everything we ship as part of the device binaries has to effectively be GPLv2 compatible |
| 11:09:10 | _bilgus | as I understood it the device only rbutil isn't |
| 11:10:08 | speachy | yeah, I get that, but I don't understand why that keeping the device firmware v2 is a desireable goal in of itself. |
| 11:10:19 | _bilgus | I don't either |
| 11:10:51 | _bilgus | I was about to say I don't see any value at resticting ourselves unless one of the current DEVs object |
| 11:11:02 | speachy | the only objections I've ever seen to v3 are of the "it prevents us from DRM &| patent shenanigans" |
| 11:11:31 | speachy | prevents us from undertaking, that is |
| 11:12:54 | _bilgus | good argument I suppose but I assume if it became a problem V4.0 is stable enough to go back to? |
| 11:13:16 | speachy | so yeah, that's why I'm asking. I don't see any practical issues with rbutil going to v3 (though that library has proven to be a lot rougher than I first thought) |
| 11:15:09 | _bilgus | yeah I'd really like to get some time to dev it against something windows 11ish |
| 11:15:16 | speachy | the v3 patent language would help protect us from other folks' shenanigans; granted it would be a phyrric victory at best given our utter lack of an ability to pay a lawyer. :D |
| 11:15:41 | _bilgus | I figure we fold if some dumb shit happens |
| 11:16:16 | _bilgus | here's our assets wait what assets its all volunteer |
| 11:25:14 | speachy | I hope to get the first pass of rbutil+7z integration done tonight. |
| 11:26:04 | speachy | but that won't get us any closer to being able to generate release packages |
| 11:26:35 | _bilgus | Issue being windows and mac? |
| 11:26:40 | speachy | and there's still the usual "latest versions of proprietary OSes break things" crap |
| 11:28:32 | speachy | yeah, I can cobble together a suitablly old system to do x86_64 and aarch64 linux AppImages, but I have zero interest in running the MacOS and Windows gauntlets to figure out what needs to be done. |
| 11:29:33 | speachy | (heck, other than a Win7 VM that I use for some device driver reverse engineering work and firmware updates, that's it) |
| 11:30:07 | _bilgus | I have a beefy kid thinkpad with either w10 or w11 on it |
| 11:32:11 | _bilgus | I think its the W520 |
| 11:34:16 | _bilgus | no W530 |
| 11:55:31 | _bilgus | back to that stm board it was what 32mb and 128mb flash? |
| 11:58:43 | speachy | 32MB SDRAM, 128MB dual QSPI flash |
| 11:58:48 | _bilgus | $100 thru mouser and a bit more on amazon |
| 11:58:49 | speachy | won't use the flash |
| 11:59:19 | speachy | on-chip there's 1MB of RAM and 2MB flash. |
| 11:59:43 | _bilgus | yeah I figured that was pretty low is it at least faster? |
| 12:00 |
| 12:00:23 | speachy | 192K of TCM RAM, the rest is slower (but still a lot faster than off-chip) |
| 12:01:59 | speachy | 64K ITCM, 128K of DTCM. Not sure if that's shared between the cores or partitioned in some way. |
| 12:02:04 | _bilgus | oh ok so it would make sense to make use of it |
| 12:02:22 | speachy | yeah, the way I see it we'd run the entire firmware binary out of on-chip RAM. |
| 12:02:55 | _bilgus | would make for some nice debugging hints too |
| 12:02:56 | speachy | (well, probably not _all_ of it, but a considerable part) |
| 12:03:21 | speachy | if I get around to finishing utf8proc that's gonna push us over 1MB bin size on most targets. :D |
| 12:03:56 | speachy | the flash will work pretty well for XIP too |
| 12:05:00 | speachy | oh, there's two cores too |
| 12:05:15 | _bilgus | I see a few things in there we can probably limit some of that once you get something working to test against |
| 12:05:25 | speachy | 480MHz CM7 , 240MHz CM4 |
| 12:05:28 | _bilgus | ^utf8proc |
| 12:05:39 | speachy | utf8proc still relies on malloc for temporary buffers |
| 12:05:42 | speachy | (boo) |
| 12:05:59 | speachy | so I gotta fix that before I can proceed on that front |
| 12:06:00 | _bilgus | I've been working on lua it does too |
| 12:06:18 | _bilgus | so tlsf is how we do it in the plugin |
| 12:06:49 | _bilgus | I have it 'fitting |
| 12:07:05 | _bilgus | but its not good yet or running |
| 12:07:18 | speachy | the part in the echo player is lower-end, single CM7 core (480MHz) but has teh same RAM/flash. |
| 12:07:40 | _bilgus | ty I was trying to figure that out before I got distracted |
| 12:08:07 | speachy | urf8proc internally always decomposes the supplied string to the internal buffer (allocated based on the size of the nput ), then recomposes it to the destination |
| 12:09:24 | _bilgus | should be able to give it @ big enough buffers and swap? |
| 12:09:33 | _bilgus | 2* |
| 12:09:58 | _bilgus | aka lie to it |
| 12:10:06 | speachy | need to change the API to allow passing in a work buffer, and use a static one passed in. |
| 12:10:19 | speachy | I think 3-4x actually |
| 12:11:09 | _bilgus | I'm thinking you might be able to get better code size doing that over implementing tlsf |
| 12:11:16 | _bilgus | maybe* |
| 12:11:40 | speachy | integrating it nito the codecs is going to be painful since it probably needs to be done one by one. We _could_ post-process the id3 struct after the fact but we'd need to effectively build a new one using the old one as a reference. |
| 12:12:26 | _bilgus | you would get a lot better path later when it comes to moving to upstream fixes keeping the malloc |
| 12:12:44 | _bilgus | I had some thoughts on that |
| 12:13:34 | _bilgus | If we do our db reads as storing the bytes position of the id3 this would allow faster lookups |
| 12:13:41 | speachy | ok, it's 4x. takes in a utf8 stream, does a decomposition pass to work out the number of unique codepoints, allocates that length * uint32_t. |
| 12:14:06 | _bilgus | phew its going to need the plugin buffer |
| 12:14:19 | _bilgus | or suspend music while running |
| 12:14:29 | speachy | up to 4x on purely the non-decomposed codepoints, and each codepoint could be broken into multiple others. |
| 12:14:58 | speachy | it'll be needed every time we parse a file's metadata |
| 12:15:16 | speachy | or every time we iterate through a directory listing |
| 12:16:26 | _bilgus | be beter to write it back |
| 12:17:08 | speachy | what I want to do is get everything internally into a consistent NFC form. |
| 12:17:42 | _bilgus | could we move some of this to the user pc ie have rb scan the whole thing then let the pc churn it or a plugin on device? |
| 12:17:47 | speachy | since our font renderer isn't ever going to deal with recomposing crap. |
| 12:17:50 | speachy | nope. |
| 12:18:04 | speachy | I mean, I wish we could, but realistically, who's ever going to run it? |
| 12:18:26 | speachy | we have filenames/directories with arbitrary unicode (and on macos the native APIs helpfully decompose everything) |
| 12:18:38 | _bilgus | people with really large libs tht don't want to wait 4 hrs for their device to do it |
| 12:18:41 | speachy | and the file contents are equally <shrug> |
| 12:18:49 | speachy | no, this has to be at runtime. |
| 12:19:05 | _bilgus | well dir cache can save us some |
| 12:19:06 | speachy | it's also needed for voicing/spelling |
| 12:19:43 | speachy | the filename side of things is going to be quite hairy so I'll deal with the metadata first (since that's nicely self-contained) |
| 12:20:08 | _bilgus | I need to look closely and get back into it but I'm pretty sure you could store the multiple refs to point at the same object |
| 12:20:13 | speachy | the other advantage of doing it in the medatata parser is that the database will get the nicely normalized strings so we dont' have to play runtime shenanigans to sort that out |
| 12:20:46 | _bilgus | thats db is first in my targets if and when I get a scripting language into core |
| 12:20:50 | speachy | I am _not_ trying to solve this for the general case (ie in the display "string to font glpyhs" code) |
| 12:21:04 | speachy | that would be pretty expensive |
| 12:21:40 | _bilgus | lua isn't unicode aware though its not unicode incompatible either |
| 12:21:43 | speachy | I've already implemetned something similar for our translation and cmdline-based voice generation code |
| 12:25:21 | _bilgus | I was looking at antirez's tcl alike picol, and jim, then at a version of picol someone ran with pickle and the fack that its 10k of code for picol, 60-100k for jim and 120k for pickle |
| 12:25:34 | _bilgus | fact* |
| 12:25:51 | _bilgus | lua tips in at 130k all in |
| 12:26:45 | _bilgus | code only mind you lua still has really bad fragmentation |
| 12:26:57 | _bilgus | I can't say for the others |
| 12:27:53 | _bilgus | I envision us running it to pre-process things then we unload the interpreter |
| 12:29:16 | _bilgus | target it for the start of audio ram and stop the world if we need to reload it (theme change) db update reload tagnav etc |
| 12:30:14 | _bilgus | ATM its all in but it might make sense to split out the vm so it can still run code |
| 12:34:00 | _bilgus | I was also thinking about PIC or maybe it would work split the plugin buffer in two for some of the smaller plugins to allow running more than one |
| 12:37:21 | | Join ShaneTalksTech [0] (~Shatech@2600:1700:60e7:f810::19) |
| 12:37:36 | *** | No seen item changed, no save performed. |
| 12:38:30 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 12:51:29 | speachy | I wonder how much PIC would bloat our plugins in general. |
| 12:51:46 | speachy | easy enough to find out. |
| 13:00 |
| 13:00:17 | | Join JanC_ [0] (~janc@user/janc) |
| 13:00:17 | | Nick JanC is now known as Guest2634 (~janc@user/janc) |
| 13:00:17 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 13:02:14 | | Quit Guest2634 (Ping timeout: 252 seconds) |
| 13:10:09 | | Quit ShaneTalksTech (Ping timeout: 276 seconds) |
| 13:27:37 | | Quit chorc (Ping timeout: 276 seconds) |
| 13:29:51 | | Join WebGuest10 [0] (~WebGuest1@163.116.130.29) |
| 13:29:58 | WebGuest10 | hello |
| 13:30:22 | WebGuest10 | are there any plans to launch rockbox on ipod nano 3rd gen |
| 13:30:24 | WebGuest10 | ? |
| 13:33:54 | | Join chorc [0] (~chorc@user/chorc) |
| 13:35:24 | | Quit WebGuest10 (Quit: Client closed) |
| 13:49:16 | speachy | "when it's working" |
| 14:00 |
| 14:11:49 | | Join ShaneTalksTwo [0] (~ShaneTalk@2600:1700:60e7:f810::15) |
| 14:20:17 | | Nick JanC is now known as Guest7323 (~janc@user/janc) |
| 14:20:17 | | Join JanC_ [0] (~janc@user/janc) |
| 14:20:17 | | Quit Guest7323 (Killed (copper.libera.chat (Nickname regained by services))) |
| 14:20:17 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 14:26:12 | | Quit ShaneTalksTwo (Remote host closed the connection) |
| 14:33:52 | speachy | hmm, PIC would make it much saner to deal with the ipod5g's varying RAM size.. |
| 14:37:37 | *** | Saving seen data "./dancer.seen" |
| 14:43:27 | | Join JanC_ [0] (~janc@user/janc) |
| 14:43:27 | | Quit JanC (Killed (zirconium.libera.chat (Nickname regained by services))) |
| 14:43:27 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 14:45:32 | | Join petur [0] (~petur@78-21-55-218.access.telenet.be) |
| 14:46:13 | _bilgus | I think the last time I tried PIC it it wasn't crazy but its been too long to remember the specifics |
| 14:46:16 | | Join JanC_ [0] (~janc@user/janc) |
| 14:46:16 | | Nick JanC is now known as Guest1874 (~janc@user/janc) |
| 14:46:16 | | Quit Guest1874 (Killed (iridium.libera.chat (Nickname regained by services))) |
| 14:46:16 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 14:55:27 | | Join JanC_ [0] (~janc@user/janc) |
| 14:55:27 | | Nick JanC is now known as Guest1164 (~janc@user/janc) |
| 14:55:27 | | Quit Guest1164 (Killed (silver.libera.chat (Nickname regained by services))) |
| 14:55:27 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 14:59:22 | | Join JanC_ [0] (~janc@user/janc) |
| 14:59:22 | | Nick JanC is now known as Guest9615 (~janc@user/janc) |
| 14:59:22 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 15:00 |
| 15:00:24 | | Quit Guest9615 (Ping timeout: 260 seconds) |
| 15:07:59 | | Quit JanC (Ping timeout: 260 seconds) |
| 15:11:34 | | Join JanC [0] (~janc@user/janc) |
| 15:19:57 | | Join JanC_ [0] (~janc@user/janc) |
| 15:19:57 | | Nick JanC is now known as Guest7662 (~janc@user/janc) |
| 15:19:57 | | Quit Guest7662 (Killed (lead.libera.chat (Nickname regained by services))) |
| 15:19:57 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 15:25:29 | | Quit JanC (Ping timeout: 265 seconds) |
| 15:27:09 | | Join JanC [0] (~janc@user/janc) |
| 15:47:52 | | Join JanC_ [0] (~janc@user/janc) |
| 15:47:52 | | Nick JanC is now known as Guest3162 (~janc@user/janc) |
| 15:47:52 | | Quit Guest3162 (Killed (tantalum.libera.chat (Nickname regained by services))) |
| 15:47:52 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 16:00 |
| 16:37:40 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:04:43 | | Quit petur (Quit: Leaving) |
| 17:58:47 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 18:00 |
| 18:07:49 | | Quit Malinux (Ping timeout: 248 seconds) |
| 18:28:50 | | Quit lebellium (Quit: Leaving) |
| 18:37:41 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:54:12 | | Nick JanC is now known as Guest9390 (~janc@user/janc) |
| 19:54:12 | | Quit Guest9390 (Killed (erbium.libera.chat (Nickname regained by services))) |
| 19:54:13 | | Join JanC [0] (~janc@user/janc) |
| 20:00 |
| 20:02:35 | | Join massiveH [0] (~massiveH@108.50.181.86) |
| 20:12:39 | | Quit bleb (Ping timeout: 276 seconds) |
| 20:37:44 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:14:49 | skrzyp | speachy: thanks for clarification and understanding :) |
| 21:18:14 | skrzyp | so, 2TB is currently the "regular" maximum, but I'm genuinely interested in that hybrid MBR+GPT option, maybe with multiple FAT32 partitions (as exFAT support won't be there yet now) |
| 21:18:24 | skrzyp | but it looks like I need to seek for other adapters than iFlash |
| 21:19:11 | skrzyp | maybe these imCort ones? Having a full fledged mSATA drive is an option, but it'll get hotter and more power consuming than microSD cards most likely |
| 21:20:10 | skrzyp | dunno about modern CF -> microSD converters, I had rather bad luck with them on Amiga and Toshiba Libretto :/ |
| 21:24:59 | braewoods__ | skrzyp, some times I wonder if it would be easier to just use a pair of high capacity SD cards in something like a xduoo x3. |
| 21:25:24 | skrzyp | braewoods__: I have xduoox3... somewhere |
| 21:25:48 | skrzyp | but I don't know about its maximum addressing of SD controller |
| 21:26:18 | braewoods__ | Ask speachy then. He should have an idea. |
| 21:26:26 | skrzyp | also, that little OLED screen is sometimes fun, but in general it's very hard to read outside |
| 21:26:32 | braewoods__ | I've used up to 512GB in systems with older micro SD card slots. |
| 21:27:37 | braewoods__ | Some days I wish rockbox had devices with wifi or similar so you could stream audio while at home or something. lol |
| 21:28:26 | braewoods__ | skrzyp, Fair, but I wonder if there's a screen filter or similar that could help there. |
| 21:28:35 | braewoods__ | no expert on outdoor visibility. |
| 21:32:12 | skrzyp | there's no such filter which will make it larger :D |
| 21:33:55 | braewoods__ | skrzyp, ok. it's just hard to maximize available storage on rockbox. |
| 21:34:42 | skrzyp | it's not like I'm 100% set in stone on that, I'll probably go with 2TB cards (or 2x1TB) first |
| 21:34:54 | braewoods__ | do you really need so much raw storage? |
| 21:34:55 | skrzyp | but I'm also researching how much experimental we can get there |
| 21:35:54 | braewoods__ | One advantage of a SD card based device is you could easily swap sd cards, kinda like changing audio discs. |
| 21:36:21 | braewoods__ | If you can't fit everything onto one storage solution... |
| 21:36:36 | skrzyp | braewoods__: I'm rarely at home with enough time to sync and organize the music library on the DAP llike people did in iTunes era, so having the raw copy of my NAS /Music dir rsync'd to /media/sdcard/ is a nice option |
| 21:36:38 | ant | speachy haven't gotten around to trying 4.0 on the 3g yet, hopefully this weekend |
| 21:38:23 | | Join othello8 [0] (~Thunderbi@100.36.176.164) |
| 21:38:33 | braewoods__ | and how much raw storage do you already use? |
| 21:38:38 | braewoods__ | o.O |
| 21:39:43 | skrzyp | braewoods__: it's about 1.2TB now, so not that big, and that's why I say sticking with 2TB is probably okay for now |
| 21:39:50 | skrzyp | just thinking in the longer term :D |
| 21:40:07 | braewoods__ | Compressed as what? FLAC? |
| 21:40:08 | ant | that's a lot of music |
| 21:40:23 | ant | i use v0 mp3 on my portables |
| 21:40:43 | braewoods__ | OPUS offers a great size to quality these days, but no idea what it does for battery life. |
| 21:42:38 | skrzyp | braewoods__: FLAC mostly. There's a recgonizable part of .MODs/.XMs and .SIDs, but these aren't such huge :D |
| 21:42:54 | | Quit othello8 (Ping timeout: 252 seconds) |
| 21:43:28 | skrzyp | Transcoding to opus might be an option, but I wonder about performance and CPU usage on older devices like 5.5g |
| 21:43:36 | braewoods__ | skrzyp, i see. you might be able to squeeze some more space via recompression if they were compressed a long time ago. |
| 21:44:02 | braewoods__ | FLAC and other implementations can achieve better compression ratios than older versions of FLAC. |
| 21:44:30 | skrzyp | Interesting, I thought FLAC is mostly a fixed format for ages |
| 21:44:48 | braewoods__ | It does I believe. But they've improved the encoder over the years. |
| 21:45:05 | ant | hasn't changed in many years though |
| 21:45:11 | ant | afaik |
| 21:45:20 | braewoods__ | Last I hear was they integrated changes from FLAKE. |
| 21:45:36 | braewoods__ | But that was ages ago. But if your collection is old enough, it might help a bit. |
| 21:45:41 | ant | free lossless audio kodec eh? |
| 21:48:04 | braewoods__ | http://cue.tools/wiki/CUETools_FLAC_encoders_comparison |
| 22:00 |
| 22:22:52 | | Quit Moriar (Ping timeout: 252 seconds) |
| 22:37:48 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 23:48:17 | | Quit massiveH (Ping timeout: 252 seconds) |
icon identifies that the person is a core developer (has commit access).