Happy New Year to everyone. I just want to share a joyous event with you, I won’t comment it at all, but just hang the pictures there for you…
Happy New Year to everyone. I just want to share a joyous event with you, I won’t comment it at all, but just hang the pictures there for you…
As it seems, we in media monitoring want to record everything. Good part of everything is still in FM radio spectrum (or AM in some flat-land countries). An usually, there are plenty of stations on the air that we have to record, at least a dozen at a given location…
Many many years ago, when I was working in FirePlay (great radio automation company and software) we had a task to produce a recorder that would record ONE channel of radio program 24/7. At that time, encoding MP3 in real-time was some kind of science, and wasn’t available but on most advanced systems that were available (I won’t try to be exact here, but it was something on the lines of Pentium 133Mhz).
So we build FireSave, first version, that was able to handle 1 channel and record it to hard drive, encoded in mp3 format. We even tried to use some obscure GSM codecs to save space even more…
Setup above required live external tuner to be connected to the Sound Blaster (yeah, really). We had some multi-channel cards but they were expensive, and using them to record a confidence and/or compliance recording would be waste of money.
Our need was expanded from one channel to several, say 4. Since we had some expertise running multiple channels, we quickly added more external tuners, replaced Sound Blaster with some multi-channel monster (it was Wave4, then Gina24, then other stuff from EchoAudio, such as Layla 3G) and finally upgraded the software so it could handle multiple channels.
It worked, with 4 external tuners attached to one PC, sometimes more, it looked like an octopus.
OK, but what if you need and want to record 150 radio station that typical country like Croatia has? You’ll be able to get some audio cards that will have up to 16 audio inputs (even mono sound will be OK), but to have that kind of external tuners, that is and could provide some kind of a problem. And yet still, they can’t all be heard in one place, so you’ll have to have multiple recording sites in order to capture everything you need.
The simple fact is that every good radio station will have its internet stream so it will be heard on the internet. And there is a way to capture that stream of the internet and save it to hard drive as you would record it. There are multiple tools on the internet that would allow you to capture internet audio streams, and you just have to choose one of them, and you’ll be able to record any radio that has its stream. Before we created StreamSink, I was extensively using StationRipper for my own purposes, and that was the inspiration that was needed to create very similar tool. It is similar in the respect that it records internet audio (and video) streams, but one thing is very different: all ‘rippers’ including StationRipper are designed to try to cut audio stream at song boundaries, creating a library of songs for the user. On the other side, our task was to create system to record internet streams in multiple formats in the archive format usable by VideoPhill Player.
It isn’t anything special – just a bunch of files named in some fashion and cut at every five minutes, with special care not to lose single byte of a stream while cutting it.
So with that system, recording 100 radio stations on a single computer is as simple as having an good internet connection present. Of course, every stream will be recorded as reliably as the server and the internet permits, and there is nothing you can do about it. When using that method, you must allow yourself to lose some of the archive sometimes, for the unforeseen facts. Again – better radio stations (the stations that you will need 100% of the archive) will have better sources, better distribution servers, and thus your archive will be better covered.
Lately (Summer 2011), there was a client that needed to record multiple radio stations as well. However, after initial investigation we concluded that radio stations that needed recording were either badly presented on the internet or not presented at all. So instead of capturing streams, we were aiming to capture radio signal from the FM directly. All we had was the antenna that was dipped in the airwaves that contained our radio stations (8 of them).
Strategy was as follows: I have a tool that can capture streams in the format that my application (the Player) needs, but we haven’t the streams. Let’s create them.
Shoutcast internet radio is on the market for decades. And it has both free and tremendous support, and their software for creating and distributing internet radio streams are as robust as they can be, since they are field tested in possibly millions of usage scenarios.
As I knew how to encode the stream, how to distribute it (locally) for the StreamSink, I just needed to capture FM signal somehow. Using 8 external tuners would be funny for the client, and I’ll probably lose them, so I did a little digging and found a beauty in form of a PCI card:
This little monster (AudioScience ASI8921) is able to capture 8 FM radio channels and give them to the rest of the system in the form of the DirectShow or waveIn API, just what we needed. Only thing left to do is to connect the antenna to the card and configure shoutcast encoder/server as needed, turn on the StreamSink, and we are recording!
The topic of drive fragmentation might be a little out in this days, but since I spent great deal of my youth watching PC Tools defragment my drive in a graphically pleasing fashion, I am inclined to think that drive fragmentation (when excessive) can severely reduce both computer performance and hard drive life.
As this might be true for the common day-to-day user, it is particularly true for corporate/enterprises that do need their data to be:
In a common computer use scenario, most of the files are there for computer to read an use, either as software that has to be loaded into memory, or documents that have to be shown to the user. Writing to the hard drive is uncommon operation (when you put it against the number of reads) and thus the drive fragmentation however present is in fact easily ignored.
In my business (my clients businesses’ to be exact) the hard drives are working in opposite. They WRITE all the time, and read only on occasions. And the problem that will surely lead to fragmentation is that in most situations they need to write MULTIPLE long files continuously. Let me try to explain what, first from the aspect of why, then move to what…
When either running VideoPhill Recorder for recording video, or using StreamSink to record internet media streams, in most cases user has MULTIPLE channels recorded on one computer. Files that are created by that recording are commonly created at one time (all of them) and are grown continuously until closed. Since Windows is, as it is now, an operating system that can’t reserve drive space in advance (maybe it can, but software doesn’t know how long the files would be) the space for them will be allocated as the time goes by. If we have 4 files that are written slowly but concurrently (and are grown at the same time), we’ll certainly have the following situation on the hard drive (I’m talking ONLY about the data that is stored here, and am simplifying physical hard drive storage as a continuous slate):
That means fragmentation. File isn’t in continuous blocks, but is scattered in evenly and can’t be read sequentially from the hard drive. You might be lucky and your blocks could be scattered in a way that sectors on the drive will be adjacent and this won’t pose a problem, but what are the chances?
And when file1 gets deleted, what remains on the hard drive? A blocks filled with nothing, left there for other files to fill them. New files will try to fill them, and the drive will soon be completely jumbled. It will all be hidden from you by the OS, but still, OS will have to deal with it.
And that is the story of 4 channels. What about situation when you have 60 channels recorded on one machine (I’m talking about internet stream recording, of course). Such an archive could be found here: http://access.streamsink.com/archive/
If you aren’t convinced that this really IS a problem, you can stop reading now.
It is feasible in situations where there is low number of channels that needs to be recorded. If you have 4 channels, you’ll create 4 partitions, and each partition will have nice continuous files written to it. Done.
However, you can’t have 50 partitions on one drive and get away with it.
Other solution for large number of channels presents itself in a form of a temporary partition for initial file recording, and then moving out the files to their permanent location later, but ONE FILE at a time, in a queue.
This is implemented in StreamSink, and it even has an ability to throttle data rate when moving the files to another drive. Only thing that is of a problem here is wasting of a temporary hard drive, because it gets beaten by fragmentation.
While I was writing the article about NAS, thought flashed across my mind – can we avoid writing to the temporary drive and reduce the load ONCE more?
Yes, we can. I know that RAM Drives are also out of fashion, but here one will come handy. It’s the shame that support for it isn’t included in the system already, so with little googling I found this: http://www.ltr-data.se/opencode.html/#ImDisk
I installed it on the testing server, re-configured the application to use new temporary folder, and from now on, it runs so smooth I can’t hear it anymore
Some technical stuff:
Take care of your hard drive, and don’t dismiss old-techs such as RAM Drives just yet.
If I was about to implement this on an application level, I would have to spend a great deal of time, and some media types won’t even be possible to implement – Windows Media for example, writes to disk or to other places if you employ magic… With use of RAM Drive, it was done in a matter of minutes.
During the years I had many deliberations over the fact if either NAS would be used or it wouldn’t be used for the video archives created by video logger system such as VideoPhill Recorder. At first, I was firm believer in one methodology, then completely turned my side to the other, and now, … Well, read on, and I’ll take you through it.
On the one side of the stake set we have actual requirements, and on the other there are considerations. Actual requirement are sometimes hard to pinpoint at first, but they always come out sooner or later.
So, let me list possible requirements that might be in effect here…
Storage for video recording (for logging purposes) needs to have following abilities:
The archive duration is directly proportional with the hard drive space that is available. To determine what kind of hard drive space you need for your first installation, you can use on-line hard drive size estimator calculator that I created right for this blog.
If you plan extend the duration of your archive one day, you have this requirement, and you have to plan for it. Having the storage at one place can simplify the adding of the drive space, but can also completely block it.
Let’s say that you have the archive of 40 channels that span 92 days (3 months). And let’s say that you decided to use 1mbit video with 128 kbit audio for the archive. By using the calculator above, you’ll find out that you have 42 terabytes of storage already in place. Even at this date, that kind of storage set in one place is kind-of-a challenge to build.
If you have already invested in 42 TB storage system, and have foresight to plan for an upgrade to say its double size for it, you are in luck. But, say that after a few more months (just 3) your management decides to expand the requirement to 12 months of storage. Wow. Now, you have to have 127 TB total. If the current system will hold that much drive space, again you are in luck, however – say it doesn’t. Your options are:
If you need everything in one place for the publishing, then this is a solid requirement. Web server will have the content on its local hard drives, and it will publish it smoothly.
But, is that really a requirement? I must admit that I didn’t see web server that properly served files from the network locations (despite the thing that there are option to do that), but I’m sure that IIS and Windows Server gurus will be able to shut me down and say that this is normal thing that is done routinely. So, if we know that each channel recorder has its own directory ANYWAY, what’s the use of having
This requirement is very common, and having NAS system as a ‘point’ it brings us that having the NAS leads us to having single point of failure. I understand that there are multiple redundancies that could be installed into the system, such as RAID 5, or obscene configurations such as RAID 1+5. Note: for later, it seems that the article author has a same opinion on it as me:
Recommended Uses: Critical applications requiring very high fault tolerance. In my opinion, if you get to the point of needing this much fault tolerance this badly, you should be looking beyond RAID to remote mirroring, clustering or other redundant server setups; RAID 10 provides most of the benefits with better performance and lower cost. Not widely implemented.
In my words: if you need such system, it’s better to have recording drives distributed on each recording machine, have RAID 5 there, and additionally have NAS (or some other form of storage) to DUPLICATE everything.
At a configuration with 4 channels recorded at one machine, and with above mentioned data rate for video and audio, each machine will produce 5 megabit of content every second. Roughly, that is .5 megabyte. Even ZIP drive could almost handle that. However, if you have 10 times that (for 10 recorders) and have central storage for the whole bunch of channels, that is 5 megabytes of data at a constant rate that never stops.
Consider that central storage in question is NAS has hard drives configured in RAID 5. That means that it will have to receive, calculate parity for, move the drive heads, write to drive, … It will be very busy NAS, and with everything else in mind, it won’t have a second of a break. Add to that occasional reading of the content from the archive diggers, and you’ll soon figure out that the NAS will have to take it all itself.
On the other hand, archive access applications such as VideoPhill Player doesn’t have anything against having the channels on different recorder machines.
Conclusion (for bandwidth issues) – having each recorder machine handle both encoding and storage for 4 channels will reduce single point of stress for both recording and the archive access.
Having dumped my intuition in this few paragraphs, I hope that I presented case that is strong enough against having NAS for video logger/archive storage. Again, everything said is from my experience on the subject, and I’m no storage expert who will talk petabytes, just a simple consultant trying to get my clients best bang for the buck. Please, I won’t mind objections to the text, on the contrary…
If the data is numeric, and it represents some series, it will be mostly represented with a graph of some sort. There are hundredths types of graphs available, and they all have some purpose, otherwise they would not exist.
However, for some special occasions, you have to see different kind of data.
Since I am developing a internet media streaming CAPTURE and ARCHIVE application (StreamSink) I am also continuously testing it on one of my servers. I am adding channels, removing them, stopping the server, sometimes something goes wrong and the whole thing freezes or crashes, so the archive I have is rather heterogeneous in quality.
Let me go through the operational view – the mere GUI of the StreamSink, so I can present some problems and solutions so far.
Several things were important to the operator of the software that had to be present on the main (status) screen. For example:
I could dwell on it but the main point of this post is something else.
The problem here is that I had to create PlayKontrol report for a demonstration purpose (for them: http://ihg.hr/), that would scan 7 days of the archive (multiple channels, of course), and produce the reports (playlists) for 300 songs.
So the problem is: to
find, in the archive that is damaged in various ways, 7 days of continuous archive that spans multiple channels.
Since I am kind of explorer by nature, I wasn’t inclined to use a solution that would present raw data as an answer, but was into thinking about seeing the data and determining the period and channels ‘visually’.
StreamSink has a integrated feature that is called ‘archive report’, that has data similar to what I need, but with it I would only get limited information. You can see the report here:
Most useful info on the report in this particular situation would be the graph on the right side of the report. Let me explain…
For each day StreamSink is able to record up to 24 hours of media. Due to network situations, it sometimes is less then 24 hours, and I decided that I would present that number in the form of percentage that archive is covered for the day. As you can see from the report, that percentage is shown for the whole archive lifetime, for last month, last week and last 24 hours.
Also, it is shown in the form of graph, where on the leftmost part of the graph is the current day, and as we go to the right, we sink onto the past, having divider lines at each 7 days. Nice, eh?
But, as nice as that report is, I can’t read what 7 days and what channels are to be scanned – I have to find another way in.
For this one, I picked something that I learned from the above mentioned report. That was:
Also I decided to show each day as a cell in a table-style matrix, where rows would be occupied by channels, and columns will be days. Time flow was inverted here, so left is past, and right is the present.
Whole thing looks like this:
Same thing little zoomed in:
Note: green is the color for the days that have 90% or more archive covered.
At last, you can see from the both pictures that much of the data is revealed at the first glance. For example, 0 means that there were no archive that day at all. Numbers below 90 suggest that either it was some problem with the channel that day, or StreamSink was either started or stopped in the middle of the day.
I could even color-code that information on the chart – but the utility will be expanded further only if there’ll be demand for it, since I know what I needed to know, from it.
BTW, I don’t want to brag here, but to code that utility it took 2-3 hours of thinking and coding, and almost no debugging. It’s most probably due to fact that I’m doing that stuff over and over again for some years