powering programmers late into the night

Latest

Hot Dog, Finally Fixed It!

Forever and a day, I have longed to be able to run ATCSMon on Linux or OS X via Wine. However, I have always experienced this nagging little bug where upon connecting to a server, the connection would time-out after a few minutes. I had many a hypothesis, and attempted to glean information from those over the years that claimed to have a working setup, only to continue to encounter the issue. Among things I had tried:

  • Almost every Linux distribution out there, from Ubuntu, Kubuntu, Debian, OpenSUSE, to Fedora.
  • Various versions of Wine, compiling from scratch, 32-bit and 64-bit permutations.
  • Sacrificing various animals to assorted Pagan gods.

A year or so ago, someone on the ATCSMon list mentioned they were rocking and rolling with a Wine setup on OpenSUSE, and I exchanged several emails. I thought things were working as I had over 15 minutes of a connection working in the wee wee hours of the morning. Upon arriving home from work in the evening though, the issue was occurring, disconnects, disconnects, and more disconnects after a few minutes. So why had it worked in the wee hours, but now the disconnects were back. I hacked again all night, and went to bed again with it working…and then the next night, disconnects. Flip flarrin flarrin filth!

As I worked on the issue again, I finally noticed something in the ‘Servers Connected’ dialog. It was roughly 22:30 when I was debugging, but the Established column had 10:29:00 in it, while the Last Updated column had 22:30:00 in it. That is odd, I had just connected a minute ago…then bam, disconnect. Could there be some sort of calculation on the ATCSMon side, looking to do some sort of keep alive, but seeing the time is over a few minute threshold due to the established/last connected difference? When the clock rolled over to a new day, and I connected, I figured out why the morning hours worked. The Established column had 00:01:00, and Last Updated was in the same format of 00:10:00. Debugging over the weekend, I confirmed this suspicion by observing my connection work flawlessly until 1PM, and then things went south.

Here are a few screenshots demonstrating the information noted above:

atcsmon-sandpoint-time-format-incorrect-3

From a failure scenario. Note the time format in the lower right corner of ATCSMon, as well as the differences in the Established and Last Updated columns.

atcsmon-sandpoint-time-format-incorrect-server-connect-timeout

After a minute or two connected in the PM hours, the dreaded Server Data Timeout message appears.

At this point, I was stumped. ATCSMon is put together mostly as a Visual Basic app from what I can deduce. I tried inspecting the binary with dependency walker as well as dumpbin to see if I could deduce a certain time API in use, and perhaps debug something on the Wine side. Alas, I was note able to figure anything out here, and I eventually threw in the towel, again.

For some reason today, while enjoying the NASCAR XFinity Series race, and processing log files from field monitoring with ATCSMon, I noticed the time format in the lower right corner of ATCSMon was in 12-hour format.  However, I use 24-hour on my OS X box, as well as all of my Windows boxes.  The gears began turning on my old nemesis…if I could get that time format to display as 24-hour, would that fix the server data timeout issues?

I went searching and found the various regional settings for time and number formats in the registry as there is no regional settings control panel for Wine.  The first setting I tried, comparing to my Windows ATCSMon installation, was the iTime value.  It was set to ‘0’ in Wine, indicating a 12-hour format, so I toggled to 1 for a 24-hour format, and, no luck.  ATCSMon still showed a 12-hour formatted time stamp in the lower right corner.  Comparing more, I noticed the sTimeFormat entry was different.  For Wine, it was h:mm:ss tt, whereas my other box was HH:mm:ss.  BINGO!  After that change and restarting ATCSMon on my OSX box, server data timeouts are a thing of the past!

After the sTime registry setting change, the Established column time format matches the 24-hour format of the Last Updated column.

After the sTime registry setting change, the Established column time format matches the 24-hour format of the Last Updated column.  The time format in the lower right corner is also now in 24-hour format.

Wow, finally, I have a solution.  Need to run for a few days here to see if the morning hours all work correctly, but I think I finally got it figured out.

05/24/2015 | Categories: OSX | Tags: , | Leave A Comment »

ddclient after Mavericks to Yosemite Upgrade

I’ve been using No-IP as a Dynamic DNS provider for sometime, and run ddclient on my main OSX box to keep things updated as IP’s come and go from the ISP, installing ddclient via Macports. I upgraded from Mavericks to Yosemite a few weeks back, and did a clean install of my ports, including ddclient, and copied over the old config file (ddclient.conf) and assumed all was well. Well, a few days ago I noticed I could not ssh into my home box, and, noticed the IP address was stale. I figured the ddclient service was hung up, and I restarted it and saw the IP address on the No-IP site:


lookout:~ $ sudo launchctl unload /Library/LaunchDaemons/org.macports.ddclient.plist
lookout:~ $ sudo launchctl load /Library/LaunchDaemons/org.macports.ddclient.plist

Last night, I restarted the router, and noticed again my IP address was not updating. Hrm, well, let us see if the ddclient process is running:


lookout:~ $ ps aux | grep ddclient
root 79284 0.0 0.0 2470252 528 ?? Ss 12:50AM 0:00.01 /opt/local/bin/daemondo --label=ddclient --start-cmd /opt/local/etc/LaunchDaemons/org.macports.ddclient/ddclient.wrapper start ; --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.ddclient/ddclient.wrapper stop ; --restart-cmd /opt/local/etc/LaunchDaemons/org.macports.ddclient/ddclient.wrapper restart ; --pid=none

Well, there is the problem — the ddclient process is no where to be found. I inspected my /opt/local/etc/ddclient/ddclient.conf, and all looked well there (should be, copied it from the Mavericks install). Next up, I ran the ddclient process manually to see what it might spit and, and now, we hit paydirt:


lookout:~ $ sudo /opt/local/sbin/ddclient
SUCCESS: updating myhost.noip.me: good: IP address set to 123.321.123.321
FATAL: Cannot create file '/opt/local/var/cache/ddclient/ddclient.cache'. (No such file or directory)

Well, that is easy enough to fix:


lookout:~ $ sudo mkdir /opt/local/var/cache/ddclient

And now, restarting the launch daemon, we now see ddclient process executing in daemon mode, and IP address changes are now picked up and updated (you know, by actually testing that things are working this time around).


lookout:~ $ sudo launchctl unload /Library/LaunchDaemons/org.macports.ddclient.plist
lookout:~ $ sudo launchctl load /Library/LaunchDaemons/org.macports.ddclient.plist
lookout:~ $ ps aux | grep ddclient
root 9343 0.0 0.1 2507660 13820 ?? S 2:38PM 0:00.16 ddclient - sleeping for 220 seconds
root 9340 0.0 0.0 2462060 1092 ?? Ss 2:38PM 0:00.01 /opt/local/bin/daemondo --label=ddclient --start-cmd /opt/local/etc/LaunchDaemons/org.macports.ddclient/ddclient.wrapper start ; --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.ddclient/ddclient.wrapper stop ; --restart-cmd /opt/local/etc/LaunchDaemons/org.macports.ddclient/ddclient.wrapper restart ; --pid=none

I will need to go poke around and see what is the expected behavior with the ddclient and the cache (/opt/local/var/cache/ddclient) directory. You can specify a tmp directory in your ddclient.conf, but there is a default used of course, but it looks like ddclient will not try to create that directory.

11/02/2014 | Categories: OSX | Tags: , | Leave A Comment »

Happy with a Hundred Buck Upgrade/Repair

Around Christmas, I built the wife a new PC, replacing the HP Slimline 5350 she had used for a number of years. While a bit slow in the tooth, it had served its purpose as a general PC well, with only a video card fan going out (I guess it had a hard drive die a few months in, but the replacement for that has worked fine). Anyway, with a nice quiet PC build for the wife (need to post the details on that build), the old gear went to my daughter. As luck would have it, about two months in, I walked into her room one evening and smelled burning plastic, and the power supply was on its way out. Unplugged it, and suffered nagging here and there over the past month to fix it.

A week back, I jumped on, and happened to find a replacement power supply for it. Being a slimline, using a Flex-ATX-like setup, the options were not great, but I managed to find a replacement by Detin:

While perusing deals, I found some refurbished SSD’s, and picked up an OCZ 100GB SSD, and snagged an ICY Dock EZ-fit Lite bay for it:

As usual, Newegg promptly shipped the order, and 2/3 of the parts showed up Thursday, with the SSD showing up Saturday. Today, I removed the old hard drive and power supply, and slapped in the replacements. The ICY Dock worked like a champ — I will have to keep it in mind as I start working in more SSD’s. The power supply was a drop in replacement, and in about twenty minutes the PC was running again.

I did a clean install of the OS, and I was very happy with the performance of the SSD. Install was rather snappy, and the OS boot time is oodles and oodles faster than the old OS install on a spinning disk. Most of all, the daughter is happy to have her PC back, and she was pretty happy with how fast it was.

04/06/2014 | Categories: Computer Hardware | Tags: , , | Leave A Comment »

Noise and Audio Crackling with a SDR RTL Dongle

When I initially started tinkering with SDR, I had picked up an R820T-based dongle from NooElec. I tinkered with it on Linux and OSX at first, but since I intended to use it with ATCSMon, I eventually ran across SDR# and had things running under Windows 8 fairly seamlessly, and ran in that manner for many months.

After moving in the late summer of 2013, and picking up a second R820T dongle, I tried running the two of them on the Windows box I had. This machine is probably pushing ten years old now. Housed in a venerable Chenbro Genie case, an Athlon dual core processor and a couple GB of RAM, plus a WD 10,000rpm Raptor powered this machine. However, it did not quite have enough umph to power two SDR# instances.

My linux box had remained powered off since the move, and since it contained a more modern setup with a quad-core processor, I figured it would be more than up to the task. Additionally, it had a gaggle of USB ports, so a few SDR dongles, iMic’s, and the like hanging off should not be an issue.

As with days of old, I tore down the old Linux box and built it back up, going through all the parts, and cleaning out years and years of accumulated fine dust. I combined this machine with some parts from the Athlon system, and had a quad-core setup with 6GB of RAM, ample hard disk space, one of the fanless NVidia cards (a GT7800 IIRC), and several quiet fans. She looked good, and booted up and installed Windows with ease.

After laying down a minimal set of customizations and programs, I figured up an instance of SDR#, and immediately I had a problem on my hands. Every few seconds, the otherwise pleasant sequence of digital signal beeps was interrupted with a crackle. That is odd, wonder what is up with the headphones I was using. Looking at the waterfall though in SDR#, I saw jitters in the waterfall every time there was a crackle. Hrmmm…this is odd. Curious, I fired up ATCSMon and tuned in to a nearby BCP and the crackling was impacting decoding as errors popped up every time there was distortion in the audio.

I tried a few things such as moving the USB dongle to a different port, ensuring the USB ports were grounded, trying a USB HUB, and all sorts of other finagling. Nothing worked. Tried the other dongle at some point as well, and still, the same results.

Eventually I resorted to google, and I ran across the following article that described a similar situation:

The forum post had a few references to disabling C1 and EIST in the BIOS. These options would disable power management, and the stepping down of the CPU. So, I headed into the BIOS of my Gigabyte GA-EP35-DS3 board. In the Advanced BIOS Features section, I disabled the following features:

  • CPU Enhanced Halt (C1E)
  • CPU EIST Function

Heading back into Windows, I fired up SDR#…and…viola. The crackling gone running a single dongle. Plugged in number two, fired up a second instances of SDR#, and a merrily receiving the dongles went. The only downside is the computer will run quite warm as the CPU is running without any kind of power saving support enabled. I was able to back down the CPU multiplier in the BIOS, slowing it down, but running a bit cooler.

I had hoped to run a virtual machine as well on this computer, but there is something around some instructions executed in a VM that interfere with the RTL R820T dongles. For example, when Ubuntu is installing updates, perhaps it is the disk IO or something, but the USB dongles will become quite cantankerous, and the signal becomes distorted, resulting in errors decoding data in ATCSMon.

03/11/2014 | Categories: Radio, Windows | Tags: | 3 Comments »

Compiling Icecast with SSL Support

On a random adventure settings up Icecast, I found the Debian packages do not have ssl support compiled in. This Fedora bug is similar to what I found on the Debian side of the house:

So, time to snag the source package and rectify things:

erben22@tipton:~$ sudo apt-get install icecast2 build-essential fakeroot dpkg-dev libssl-dev
erben22@tipton:~$ sudo apt-get build-dep icecast2
erben22@tipton:~$ apt-get source icecast2
erben22@tipton:~$ cd icecast2-2.3.3
erben22@tipton:~$ dpkg-buildpackage -rfakeroot -b
erben22@tipton:~$ cd ..
erben22@tipton:~$ sudo dpkg -i icecast2_2.3.3-1ubuntu1_i386.deb

In these few magic lines, we ensured some helper tools were installed, as well as the libssl-dev package. Then, we ensured we had all the dependencies for the icecast2 package. With those basics in place, we grabbed the source package, and simply built it. With libssl-dev on the system, the configure step finds the libssl headers and adds -lssl to the linker options.

The only omitted step here would be to run dch -i to edit the changelog and assign a new version. This step would help ensure your build sticks when there are repository updates for the icecast2 package.

Before:

erben22@tipton:~$ ldd /usr/bin/icecast2 | grep ssl
        <crickets>
After:

erben22@tipton:~$ ldd /usr/bin/icecast2 | grep ssl
	libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0xb7683000)

Groovy, now we can modify the icecast2 config file (/etc/icecast2/icecast.xml) to flip on ssl support, avoiding those pesky clear-text authentication paths when admin’ing Icecast:

    <!-- Port for users to connect to streams.  
         Any logins here are clear-text -->
    <listen-socket>
        <port>8000</port>
    </listen-socket>

    <!-- Our admin port. -->
    <listen-socket>
        <port>8001</port>
        <ssl>1</ssl>
    </listen-socket>

    <paths>
        <basedir>/usr/share/icecast2</basedir>
        <logdir>/var/log/icecast2</logdir>
        <webroot>/usr/share/icecast2/web</webroot>
        <adminroot>/usr/share/icecast2/admin</adminroot>
        <ssl-certificate>/etc/icecast2/sample.pem</ssl-certificate>
        ...
    </paths>

03/10/2014 | Categories: Linux | Tags: | 6 Comments »

GE MDS Toolbox Software – Windows Runtime Error 7 Spelunking

As I poke more at ATCSMon, I have been getting my fill of eBay again and searching for long-discontinued, but inexpensive and perfectly useful radio-related gear. I have a RadioShack PRO-2006 that is beat-up, but works well, and then a couple RTL2832U/R820T dongles already, but I ran across an MDS 2310a up for auction, and snagged it for about $45.00 including shipping.

I will need to write up another post on some details on getting it up and going. I did eventually get it working with some great info from the ATCSMon Yahoo Group file archive (write-up on using the MDS 1000u, a predecessor to the 2310a, but otherwise very similar in terms of getting ATCS data out of the puppy). The radio uses a serial interface, and after wiring up a DB25 connector to RX, TX, and ground to a DB9 connector, then DB9 cable to a Keyspan USA-19HS USB-Serial adapter, I was ready to try programming the radio. Yes, this thing is just a box with a DB25 connector, six LED’s, a power connector, and an N antenna connector. No knobs here to adjust the tuning here. Anyway, that later post will show some of the details getting all those pieces together. It was an enjoyable, challenging event, but I did do a little happy dance a few times over this past weekend.

My first MDS 2310a cranking away, pulling in ATCS-related data and handing over to the computer to further process.

My first MDS 2310a cranking away, pulling in ATCS-related data and handing over to the computer to further process.

More to the point of this post. My initial setup had been using an HP Envy-X2, and connecting via a Keyspan USA-19HS to the serial connection. I went out and installed the GE MDS Toolbox software to get the MDS Radio Configuration Software app laid down, and the first try went off like a champ, and I had an ATCS frequency programmed and was hearing data.

However, I wanted to change the frequency, and for some reason, the setup on the Envy-X2 stopped working, and it would not establish communication with the 2310a any longer. Tried rebooting and all that jazz over the course of a few hours, and nothing. I even rebuilt my DB25 cable, all to no avail. So, I dug out a PC that still had a serial port (and a parallel port, oh my!), and tossed on a 32-bit OS. Ah yes, a note here, the GE MDS software is long since out of support, and while it runs on Windows 8.1, most of the utilities including the programming app are 32-bit only.

With a Windows 7 x86 install up and running, I tossed on the GE MDS software, and ran into a Windows Runtime Error ‘7’ when I would launch the MDS Radio Configuration Software app. I thought I was missing a .NET runtime, so tried installing a variety of those, to no avail. Eventually, I installed Dependency Walker, profiled the launch of the app, and noticed a few dll’s that were not found. These included an fm20enu.dll. After some poking, I ran across this post related to some other GE software:

https://groups.google.com/forum/#!searchin/kml-support-getting-started/fm20/kml-support-getting-started/zCC3jwf5QLI/u0Aj_73ZIekJ

It did not necessarily solve my issue, but gave me enough of a push to solve it. I hopped back to the Envy-X2, hit the system32 directory, and sure enough, it had a fm20enu.dll file in there. I suspect this came from either Visual Studio or the Office 2013 install on it, although I did not confirm. After plucking that dll from the Envy-X2, and dropping it on the Windows 7 x86 system, the MDS Radio Configuration Software app launched successfully.

Oh yeah, then the moment of truth, tried the rebuilt cable directly to a real serial port, and viola, I was able to program things again. Still have not been able to get the Keyspan USA-19HS adapter to work again, but it worked once! Perhaps in my initial connector I had some pins making contact and caused damage to the Keyspan adapter? Will have to look into things there some more, or, go dig out one of the old laptops that has a serial port to tote around for programming the 2310a. Have one in the fleet so far, but probably will not be alone for too long. Kicking myself a bit as I had passed on an auction for 4 MDS 2310a’s a few months back, and they went for about $60.00 total.

02/13/2014 | Categories: Radio | Tags: | 1 Comment »

Setting up Transparent Bridging: Century Link Zyxel Q100, Actiontec C1000A, Airport Extreme

This is an abbreviated collection of information from some tinkering months and months in the past. I have had Century Link as an ISP for several years, and had been using one of their modems as the main router/DHCP/DNS/port mapper for my home network. I had a Zyxel Q100 which does not have wireless support, and I used an Airport Extreme to handle the wireless access point side of things. An issue came up at work with some router and ISP configurations, and after I could reproduce it with my network, I was curious if the way the Airport Extreme managed DNS and DHCP was similar. Enter the world of transparent bridging.

With the Zyxel Q100, I never recalled, and if I had, I did not squirrel it away, entering any user or password information, and I think its configuration was fetched from Century Link at startup. To setup the Q100 as a transparent bridge, I would need this information to plop into the AirPort Extreme’s PPPoE configuration.

I went hunting for info on the Q100, but struck out. I had telnet enabled and poked around, but could not locate any config files that pointed me at what I was looking for. Eventually I ran across information for the Actiontec PK5000, and it lead me down the right path:

In a nutshell, the process:

  • Enable telnet and head on in.
  • Run the ps command, looking for the pppd process, and note the process ID.
  • Execute cat proc//cmdline
  • From the command line detailed output, as Cody describes on his page, the username and password will be embedded in the command string after the user and password tokens.

With this information in hand, the next steps:

  • Set the Q100 into transparent bridging mode.
  • Configure the AirPort Extreme’s internet options to connect using PPPoE, and enter the username and password (username needs to be the full email address such as foo@qwest.net).
  • Save/update the configurations.
  • Connect one of the LAN ports from the Q100 to the WAN port of the AirPort Extreme.
  • Reboot each device.

The AirPort Extreme takes maybe 30-45 seconds to login and bring up the network stack, but it should then happily be acting as the router for your network, transparently using the Q100. One can then setup the AirPort Extreme to dish out DHCP addresses, handle port mapping, etc.

After running my Q100 and AirPort Extreme with this configuration for a number of months, I moved, and through a comedy of errors with Century Link, I received an Actiontec C1000A, a wireless access point/router. With a healthy amount of tinkering with the AirPort Extreme to setup IPv6 and port mapping, as well as DHCP reservations, I employed a similar trick. The C1000A actually allows you to see your username and password when your reset it and set it up the first time (the Q100 may just as well, but I have not tried that path). pidstat is available on this modem and simplifies things a bit:

01/21/2014 | Categories: Networking | Tags: | 4 Comments »

No USB Devices Visible with VirtualBox on Ubuntu 13.10

Tinkering with a USB SDR dongle, I wanted to have a VirtualBox VM on my linux box be able to access the USB dongle. I noticed there were no USB devices available though. I had the extensions pack installed, so hopefully it is some USB-related permissions issue, and finding this post, it confirmed that suspicion. I needed to add my user to the vboxusers group:

erben22@harriman:~$ sudo adduser erben22 vboxusers
Adding user `erben22' to group `vboxusers' ...
Adding user erben22 to group vboxusers
Done.

Viola, we are in business now:

VirtualBox USB settings dialog after adding user to the vboxusers group.

VirtualBox USB settings dialog after adding user to the vboxusers group.

01/04/2014 | Categories: Linux | Leave A Comment »

Failed to Open rtlsdr Device Issue

Now that I picked up a second SDR stick (picked up a second Nooelec R820T-based dongle), I have been experimenting with various ways to use two of them with ATCSMon. I am over dinking with it on the linux box, and after compiling rtlsdr, after a reboot, running rtl_test (or rtl_tcp), I ran into a “Failed top open rtlsdr device” message.

erben22@harriman:~$ rtl_test -t
Found 1 device(s):
  0:  Generic RTL2832U OEM

Using device 0: Generic RTL2832U OEM

Kernel driver is active, or device is claimed by second instance of librtlsdr.
In the first case, please either detach or blacklist the kernel module
(dvb_usb_rtl28xxu), or enable automatic detaching at compile time.

usb_claim_interface error -6
Failed to open rtlsdr device #0.

Since I do not need the DVB side of things, with info from this post, I created a blacklist-dvb.conf file in /etc/modprobe.d, and away I go after a reboot:

# Blacklist entries to prevent the DVB side from hooking
# an RTL2832 stick for TV usage instead of the desired usage
# with rtl_sdr.

blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830

01/04/2014 | Categories: Linux | Tags: , | 2 Comments »

Fidgeting with Darkice

After fidgeting with getting audio working on a Raspberry Pi the other day, I was on my way to setting up Darkice to forward audio from my scanner to Icecast to distribute the stream (using the guide from Steffen Muller in his Live mp3 streaming from audio-in with DarkIce and Icecast2 on Raspberry Pi post).  Things went smoothly, and I had Darkice connecting to the Icecast service, and from there, clients such as iTunes, VLC, etc could connect to the Icecast stream.  Groovy. (Note, at this point, I had just been running darkice from the shell, not as a service. Hold on, things get fun soon).

Now, I wanted to get the darkice service up and going so things could be headless and seamless, just fire up the scanner, fire up the Pi, and away things would go. First, I updated /etc/default/darkice and set the RUN parameter to yes. Then started the service, and whelp:

erben22@sago ~ $ sudo service darkice start
[FAIL] Starting Live audio streamer : darkice failed!

After some digging, I ran across a few posts of interest, with this one providing the details needed to get the service going:

A diff file, darkice-init-script.diff, contains the changes I made, but the big two changes are to pass in the –make-pidfile flag to the start-stop-daemon call during start of the service, and then to remove the $PIDFILE when the service is stopped. With those, the darkice would successfully run as a service.

I cleaned up all the configurations, ensured it all worked, then decided to reboot my Pi to ensure everything started up correctly at boot.  Sigh, here we go, again. Upon reboot of the Pi, I tried to reconnect VLC to the stream, and an error popped up.  Inspecting, the Darkice process was not running:

erben22@sago ~ $ ps aux | grep darkice
erben22 11095 0.0 0.1 3544 808 pts/0 S+ 21:52 0:00 grep --color=auto darkice

Well, that is no good. I tried to start the service manually, and viola, all was good:

erben22@sago ~ $ sudo service darkice start
Starting darkice...
[ ok ] Starting Live audio streamer : darkice.
erben22@sago ~ $ ps aux | grep darkice
nobody 11332 12.0 0.6 17812 3204 ? SLl 21:58 0:01 /usr/bin/darkice
erben22 11359 0.0 0.1 3544 808 pts/0 S+ 21:58 0:00 grep --color=auto darkice

Maybe there was a fluke? Rebooted…same thing. Started the service manually, worked fine, sigh*2. I added a fair amount of logging to various steps of the startup script (/etc/init.d/darkice). I eventually removed the –background parameter to start-stop-daemon and dumped the output of the call to darkice, and was able to see the issue at startup:

start-stop-daemon --start --verbose --make-pidfile --pidfile $PIDFILE \
--chuid $USER:$GROUP --exec $DAEMON -- $DAEMON_OPTS &gt;&gt; $STARTUP_LOGFILE

case start: Starting Live audio streamer darkice
Running check
start_server: going to log start-stop-daemon info out
start-stop-daemon --start --make-pidfile --pidfile /var/run/darkice.pid --chuid nobody:nogroup --exec /usr/bin/darkice --

DarkIce 1.2 live audio streamer, http://code.google.com/p/darkice/
Copyright (c) 2000-2007, Tyrell Hungary, http://tyrell.hu/
Copyright (c) 2008-2013, Akos Maroy and Rafael Diniz
This is free software, and you are welcome to redistribute it
under the terms of The GNU General Public License version 3 or
any later version.

Using config file: /etc/darkice.cfg
Using ALSA DSP input device: default
can't create local dump file dump.ogg
Could not set POSIX real-time scheduling, this may cause recording skips.
Try to run darkice as the super-user.
DarkIce: DarkIce.cpp:1273: can't open connector [0]
start_server call result was 0
case start: else, HOUSTON, something is wrong

At startup, the message DarkIce: DarkIce.cpp:1273: can’t open connector [0]
occurs. From what I could deduce, it appears that at the point in time darkice starts up, alsa is not available. I tried setting darkice to be the last service to start (sudo update-rc.d darkice defaults 99), but without any luck. Thinking maybe there was an issue with the darkice, alsa, etc packages on the Pi, I checked a few Ubuntu installs, a 13.10 setup on one of the boxes, and when that had the same issue, I tried the VM route with Ubuntu 13.10 server, and reproduced the same issue.

At this point, I threw in the towel, and went searching for alternatives to darkice. This led me to liquidsoap, and that is a whole other blog post or seven. A quick update though…at some point after installing liquidsoap, I noticed darkice was running after a reboot. I have yet to go back on a VM and see if just installing liquidsoap was the magic touch, but should you be sold on darkice, give that a shot, perhaps it will work out for you.

01/02/2014 | Categories: Linux, RaspberryPi | Tags: , , , | 1 Comment »

« Older Entries