Re: [RDD] Why is it so?
On 02/02/2018 02:48 PM, Bill Putney wrote: wget --post-data 'user=_/username/_&password=_/password/_' http://www.xyz.org/downloads/Current.mp3 ...Using the Firefox browser on the same Rivendell machine and filling in the username and password in the pop-up then right-click and save always works. Hmm, using the POST method with this string is not the same thing as a right-click then save in Firefox. Try this command instead: wget --user=username --password=password http://www.xyz.org/downloads/Current.mp3 Why it works in OS X I don't know, but the pop-up username/password prompt from a right-click then save in Firefox is an authenticated GET not a POST. Hope that helps.__ ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Storage hard drives
On 01/24/2018 01:29 PM, Cowboy wrote: ... Back when I was doing that sort of thing, Seagates dropped heads, WD lost spindle bearings. ... I remember those days. But, as Paul Harvey would have intoned, in the 'For What It's Worth' Department, I just this past fall decommissioned a Red Hat Linux 5.2 (NOT RHEL 5U2, but 1998-vintage RHL 5.2) server (AMD K6-2/400 processor on a VA-503+ motherboard) with a Western Digital Caviar 6GB drive that had run nearly continuously since September of 1997 (original motherboard was a dual PentiumPro made by SuperMicro, upgraded to the VA-503+ in 1999 (the VA-503+ was a year old by then)). It still boots as of last week, but it was beginning to throw soft errors at an increasing rate. The 30GB Maxtor (now of course owned by Seagate, and the source of the original Enterprise line of drives) in the same chassis was showing no errors to speak of. I don't recommend doing that, but, again, FWIW. I read the Backblaze report quarterly. Good stuff, and real data on 24x7x52 operations. Very useful for broadcast, where your need that same or greater reliability, especially in the automation side of the house! ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Storage hard drives
On 01/24/2018 11:41 AM, Andy Higginson wrote: ... I know that some people don't like this, however I work on the basis that is there is an issue with a batch of drives, then you are not going to get 2 to fail at about the same time. You have 3 companies to make your choice from - Seagate, Toshiba and WD, and all of these will be from totally different factories so you shouldn't come unstuck. For what it's worth, the storage company Backblaze produces a quarterly hard drive failure rate report that is publicly available. Backblaze currently has over 400 petabytes (400,000 terabytes!) of online storage. Their Q3 2017 report can be found at https://www.backblaze.com/blog/hard-drive-failure-rates-q3-2017/ Also for what it's worth, my own experience is quite similar, in that I mix manufacturers within arrays myself; I'm not alone, as $dayjob's EMC Clariion arrays have mixed manufacturers within RAID groups (we have a somewhat paltry 750TB of online storage at the moment, a drop in the bucket compared to Backblaze). Most are ES-series Seagates, but there are Hitachi and Toshiba drives in the array. Many have been spinning for almost ten years with low error rates (the EMC FLARE software proactively hot spares based on statistical data, so drives are typically faulted and hotspared pre-failure, but we have had a couple of dozen or so out of >300 drives hard fail in the past ten years). ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] God, I hate systemd
On 12/04/2015 06:37 AM, Cowboy wrote: And I don't disagree with anything you wrote, but there is no heads-up warning that SELinux is ENFORCING as shipped. Things just silently fail to work. Once you know, it's OK. This was true with CentOS 6, too. For that matter, I'm trying to remember the last CentOS release that didn't have SELinux in Enforcing (targeted) mode by default. to the best of my recollection, CentOS 4 shipped with Enforcing as the default, but that's been quite a while ago, and even then I started out with WBEL 4 and 'cross-graded' to CentOS 4 using yum. With 6 you got an AVC denial to the desktop; I haven't yet experienced one with 7 so I can't comment on whether it sends it straight to the desktop or not. Just trying to save some folks the grief I've already suffered. Oh, I appreciate that, for sure. I would just say that a blanket 'disable SELinux' is maybe the wrong advice to give, that's all. But, then again, I do IT for a living; as a radio engineer doing IT as a secondary thing perhaps 'disabling' is the correct advice. But my experience is that if someone is able to follow the 'disable' advice that same someone is likely able to follow a 'permissive' mode advice which has less steps to do when or if you want to go back to 'enforcing' mode once you've learned more about why you would want to have SELinux in the first place. Just my opinion, though. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] God, I hate systemd
On 12/03/2015 02:18 PM, Rob Landry wrote: There seems to be no reliable way to suppress the GUI; I want to do that on the server I just built, because if someone logs in, the machine locks up. I can ssh in, or log in to the console ater pressing Alt-F1, as often as I want, and the server will keep running, but if anyone logs into the GUI, the machine freezes. So, I want to suppress the GUI. This was easy in the days before systemd; now, it seems to be impossible. I am going to have to reinstall the operating system and specify no GUI. The nuclear sledgehammer would be 'apt-get purge lightdm' (or gdm, depending upon which is installed) (took me a bit to find the command; I'm a CentOS user, and the equivalent would be 'yum remove gdm' on CentOS 7. Which doesn't ask to remove as many packages as I thought it would.) Expect a lot of packages to be uninstalled, although it might not be as many as I think. You can also try the solution mentioned at http://ask.xmodulo.com/boot-into-command-line-ubuntu-debian.html but some forum posts seem to indicate that the 'text' parameter to the kernel may or may not work with Deb 8. Hope that helps. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] God, I hate systemd
On 12/03/2015 03:45 PM, Cowboy wrote: On 12/03/2015 03:29 PM, Rob Landry wrote: I haven't tried CentOS 7 yet. My latest major pain, be aware that CentOS-7 ( and RHEL 7 ) now come shipped with SELinux set to ENFORCING, which means that many things you'd expect to work, just don't, and silently. Woah there, Cowboy all SElinux denials are recorded as avc denials in /var/log/audit/audit.log by default. It will be increasingly difficult to run without SELinux, at least on CentOS. But, CentOS 6 also ships with SELinux set to ENFORCING by default, too; it's not new with CentOS 7. Change it to DISABLED and things go as you would expect. You can also change it to PERMISSIVE and things work, and the system records where they would have broken, and the system continues to record the proper contexts so that you can go back to using SELinux without a complete filesystem relabel. Learning to use SELinux with the booleans and knobs that Red Hat has provided isn't that hard, and it is a great extra layer of security on critical systems. I have seen attempted attacks that were thwarted with SELinux (and one was on a system that was not internet-connected; there just happened to be a virus-infected Windows machine on the same LAN). But, that's just my opinion. but, well, I do Linux servers as part of what I do for a living. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Still don't know JACK
On 06/08/2015 09:25 AM, Rob Landry wrote: Methinks JACK is not ready for prime time. For what it's worth, while it's not for using Rivendell, I use JACK every single week to do production on my CentOS 7 laptop, using Harrison Mixbus to produce my weekly radio broadcast for a local AM. I use QJackCtl to start it, and I am using the built-in audio device at the moment. To do this, I just used the bog-standard CentOS 7 repositories and the jack packages in those, along with my own qjackctl package built from source RPM. I am doing absolutely nothing custom related to pulseaudio, alsa, or jack for this; yes, some of the time jack will refuse to start the first time I click 'start' in Qjackctl, but it will start the second time. Can you post the log of the start attempt? ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Tascam US-122
On 02/13/2015 10:10 AM, Morten Krarup Nielsen wrote: It's the plain old US-122 (without L or MKII) I actually was asking Mark which one he had, as he is the original poster. I know which one the howto is written for, and how old that howto is (Fedora Core 5 is in the CentOS 5 age range). I remember trying several years back (prior to the release of CentOS 6) to get my US-428 (and later a US-224) to work, and finally just using AVLinux instead, since it worked out of the box with AVLinux with no extra tweaks required. I did get it working with Fedora 14 several years back, which would be very similar to getting it to work on CentOS 6, but I've misplaced my notes on the details necessary. I have a US-144 (which needs the US-122L driver and a USB 1.1 port or hub to work, and acts like a US-122L, and it works out of the box on CentOS 7). I also have a US-428 and a US-224, which act more like the older US-122 and need the whole us-x2y stack, which is present in CentOS 7, but I've not physically tried it as yet. For the usx2y stack, you can get the two main rpms you will need from the linuxtech repo (see http://wiki.centos.org/AdditionalResources/Repositories for a link), or you can use the LinuxTECH backports repo and pull in a newer ALSA stack. The two core rpms you need are alsa-tools and alsa-tools-firmware. You will then need to find the actual firmware. CentOS 7 includes these packages out of the box, but CentOS 6 does not. You could alternatively attempt to install the alsa-tools and alsa-tools-firmware from the updates of Fedora 12 (for x86_64, a direct link to the first of these is https://dl.fedoraproject.org/pub/archive/fedora/linux/updates/12/x86_64/alsa-tools-1.0.22-1.fc12.x86_64.rpm ). Fedora 12 shipped ALSA 1.0.20; Fedora 13 shipped 1.0.23, and EL6 shipped 1.0.22. Likewise, you could attempt to install the alsa-firmware package from either F12 or F13 even though there will be version skew. It helps to remember that EL6 is something of a hybrid of F12 and F13 with other versions of packages thrown in, and many packages yanked out. Many F12 and F13 (and even F14) packages will install just fine in EL6, but since updates have been backported into EL6 many will now, so that might or might not work. The LinuxTECH packages are built with updated EL6, but there's not an alsa-firmware package there. And the F12/13/14 packages will not get updated, so installer, beware. I hope some of that scatteredness helps a bit. These older Tascam USB interfaces have been orphaned by Tascam, but they still provide excellent converters and excellent quality. The control surfaces on the US-428 and US-224 can be made to work on Ardour/Mixbus, too, and bring more of a traditional mix experience to working in that DAW. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Tascam US-122
On 02/11/2015 07:18 PM, Mark Emanuele wrote: How do I get my Tascam US-122 to be used by the centos linux OS and Rivendell? ( I am using the latest combined centos/Rivendell install) Which US-122 do you have? Is it the US-122, the US-122L, or US-122MKII? ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Volume
On 01/20/2015 09:57 AM, Al Peterson wrote: LOL "Well worth the price". Mixbus can be had right now from the website for $39 (http://harrisonconsoles.com/site/store-mixbus.html) It is a steal at $39; the 'normal' list price is $219, and worth every penny; but, yeah, they run specials occasionally. I've also purchased several of the plugins, and I purchased Mixbus itself the month it was introduced in 2009; I even bought a Mac OS X machine on which to run it afterwards (I purchased it early in hopes of getting the Linux version either free or for reduced cost, which happened a year or so later, after I got the OS X box); since then it has been ported to Windows and the Linux.. I converted my purchase to a subscription in 2013 (which also benefits Ardour development, as well as you sometimes get a new plugin free or get deep discounts on new plugins, like the XT-BC/XT-VC pair). The Harrison DSP code is legendary, and is essentially the same code that runs on Harrison's large format digital consoles. Let's see, the initial price was as I recall $79; I paid for the 2.0 upgrade at $99; the XT mastering eq for $69; the 'Essentials' pack for $39; and I've subscribed at $9 a month since 2013. Worth every penny. Just the de-esser, XT-BC, and XT-VC plugins make vocal production a snap. The character plugins (XT-BC and XT-VC) are 'tracking' EQ's and have smooth sound. Yes, all of this on Linux, OS X, and Windows. On OS X, AudioUnit plugins are fully supported; on Windows, VST's are supported, so you can use Ozone etc within Mixbus. I started with Ardour and a smattering of plugins, doing the final mastering with Jamin. These days, it's Mixbus or nothing, as far as I am concerned. If you like and can use Ardour, you'll absolutely love Mixbus. And their support has been great in my experience. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Volume
On 01/19/2015 01:49 PM, Robert wrote: There is no difference between a DAW and a straight desk with mixers turntables tapedecks and some FX in the rack. There is a thread on gearslutz.com about this. a very long thread (215 pages at the moment). See: https://www.gearslutz.com/board/showthread.php?t=463010 I personally use Harrison Mixbus on Linux for all of my production DAW needs, with any mastering that might need doing after the top-of-the-line Harrison DSP handled in Mac OS X by Audiofile Engineering's Triumph and iZotope's Ozone. These days I've found that the Harrison plugin bundles in Mixbus have drastically reduced my need for Ozone, and so the only post-mix processing I do is exporting to mp3 or whatever using either lame from the command line or Audacity if I want to do a quick audition of what Mixbus generated. Mixbus is a fantastic DAW; the mixer acts just like an analog desk (and Harrison desks are seriously high-end), and if you have a supported control surface you can mix as if you were at an analog desk. I'm using CentOS 7, and so far for straight mixdown production with Mixbus 2.5 I haven't had any issues at all, with the minor exception of getting qjackctl to build. I need to pull out the Tascam US224 or US428 I have and see if low-latency overdubs and punch-ins still work well. No, Mixbus is not fully open-source; the DSP plugin (which uses LADSPA) is closed source, but the DAW is based on Ardour 2.x and is fully open source. It's well worth the price for serious production, though. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Volume
On 01/19/2015 11:39 AM, Jay Ashworth wrote: - Original Message - From: sas...@radio42.de 2015-01-19 16:07, Cowboy wrote: Rivendell, being a *professional* automation system by and for *professional* broadcasters, I can see where the production rat has spent hours getting a piece "just so" to have it destroyed by a machine's idea of what "sounds even" to a human. "Rivendell, being a *professional* automation system" -> That's one reason more why Rivendell might need Loudness Normalization. ... Big disagree. In times of the loudness war it is even more necessary to have a proper (loudness) normalization. ... "Normalization", of whatever type, is something which happens inter-track, across a library, not intra-track, inside a single song. This is a rather interesting discussion. I remember back in the 90's, when the CoolEdit 'normalize' was peak only in nature, of going through tracks and peak normalizing everything during initial production. Yes, I know that means different tracks had (and have) different 'loudness' since loudness has almost nothing to do with peak amplitude. But I also knew that the Optimod at the transmitter was going to completely blow away any and all loudness normalization I was doing anyway. I peak normalized for a completely different reason than loudness levelling (which peak normalization doesn't do anyway): maximizing signal to quantization noise ratios. With 16 bit audio, peak normalization can make things sound marginally better when it is being mashed and munged by the Optimod or Omnia at the transmitter. In my case, it was for an AM, where modulation isn't just about loudness, but also about coverage; if the positive peaks were hitting anything less than 110% the GM wasn't happy, at all.. With 24 bit production being somewhat the norm these days, the S/N ratio, at least for quantization noise, isn't nearly as important. But getting the loudness 'just so' still runs afoul of the processor at the transmitter; that is, a machine is making loudness decisions for you anyway in the air chain. And the AM Optimods do some of the absolutely most invasive processing on audio that you can imagine; the old 9100, for instance, started out with a phase scrambling all-pass filter, which mangles peaks like nobody's business. Bob Katz' Mastering Audio book covers this thoroughly, by the way, and should be required reading for anyone producing cuts for air. Hi Jay; different audience from NANOG, no? ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Broadcast Appliance v2
On 11/05/2013 11:05 AM, Wayne Merricks wrote: Hi, I feel like I'm missing something here, where are the links to this mythical v2 appliance? Was kind of hoping CentOS would move to a newer kernel than 2.6 for hardware support reasons but nevermind. Did anyone make any progress on the gpio drivers under 3.x kernels? I'm toying with a ras-pi as my "gpio card" should be able to use rmlsend to achieve the same results either way. For newer mailine kernels, see the elrepo repository (www.elrepo.org) and use their 'kernel-ml' package. Do note that kmods built for the stock kernel likely won't work for the kernel-ml kernel. ELrepo is by far the easiest way to get a newer kernel, or to get more hardware drivers for the stock CentOS kernel. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
