search for: grungi

Situation:? * remote virtual server with very little storage (estimate: I can spare about 40G for music) * local music collection of ~80G in all sorts of formats - lossy in varying quality, some lossless too Vision: * stream my whole music collection randomized so I can listen to it anywhere Plan/Idea: * Locally transcode everything to one format that results in files that are?

Opus or AAC will give you comparable results at reasonable bitrates (~128k). Though, I would suggest finding a way to get more storage. You could upload to Backblaze B2 or AWS S3 for pennies, if your current host won't let you upgrade. On Sat, Apr 15, 2023 at 3:36?PM D.T. <ohnonot-github at posteo.de> wrote: > Situation: > > - remote virtual server with very little

I created some test samples and transcoded to FDK AAC and libopus at fairly low bitrates - I cannot recreate what bothered me about Opus & noisy music previously. It also seems I cannot tease ffmpeg into encoding FDK's AAC with VBR. As it stands, Opus clearly wins in this scenario.* Q: Is it possible to stream in variable bitrate? * ffmpeg -i "$track" -vn -ac 2 -c:a libfdk_aac

Raghavendra, I've commited my tests case to https://github.com/powool/gluster.git - it's grungy, and a work in progress, but I am happy to take change suggestions, especially if it will save folks significant time. For the rest, I'll reply inline below... On Mon, Mar 5, 2018 at 10:39 PM, Raghavendra Gowdappa <rgowdapp at redhat.com> wrote: > +Csaba. > > On Tue, Mar 6,

On Tue, Mar 6, 2018 at 10:22 PM, Paul Anderson <pha at umich.edu> wrote: > Raghavendra, > > I've commited my tests case to https://github.com/powool/gluster.git - > it's grungy, and a work in progress, but I am happy to take change > suggestions, especially if it will save folks significant time. > > For the rest, I'll reply inline below... > > On Mon,

On Tue, Mar 6, 2018 at 10:58 PM, Raghavendra Gowdappa <rgowdapp at redhat.com> wrote: > > > On Tue, Mar 6, 2018 at 10:22 PM, Paul Anderson <pha at umich.edu> wrote: > >> Raghavendra, >> >> I've commited my tests case to https://github.com/powool/gluster.git - >> it's grungy, and a work in progress, but I am happy to take change >>

[cc'ing to R-devel] It's moderately obscure to me too, but ... There are two sets of bessel code in the package, one in C++ from Chris Bond and the other in FORTRAN from Netlib (I think). The FORTRAN code is the one that's giving trouble, you might try just removing the FORTRAN code from the src directory and trying again.

+Csaba. On Tue, Mar 6, 2018 at 2:52 AM, Paul Anderson <pha at umich.edu> wrote: > Raghavendra, > > Thanks very much for your reply. > > I fixed our data corruption problem by disabling the volume > performance.write-behind flag as you suggested, and simultaneously > disabling caching in my client side mount command. > Good to know it worked. Can you give us the

Raghavendra, Thanks very much for your reply. I fixed our data corruption problem by disabling the volume performance.write-behind flag as you suggested, and simultaneously disabling caching in my client side mount command. In very modest testing, the flock() case appears to me to work well - before it would corrupt the db within a few transactions. Testing using built in sqlite3 locks is