<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Broadcast Technology Service Management</title>
    <link>http://www.broadtechsm.com/</link>
    <description>Recent content on Broadcast Technology Service Management</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 12 Apr 2024 09:00:00 -0700</lastBuildDate><atom:link href="http://www.broadtechsm.com/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Media IP Troubleshooting Tips and Tricks</title>
      <link>http://www.broadtechsm.com/guides/troubleshooting-moip/</link>
      <pubDate>Fri, 12 Apr 2024 09:00:00 -0700</pubDate>
      
      <guid>http://www.broadtechsm.com/guides/troubleshooting-moip/</guid>
      <description>::: notes Good morning. I want to quickly introduce myself. I&#39;m a Principal Engineer on SirusXM&#39;s Media Content Engineering architecture team, where we design linear and file-based media technology systems that power the audio, metadata, and video content on all the SirusXM and Pandora distribution platforms. ::: ### Topics :::::::::::::: {.columns} ::: {.column width=&#34;50%&#34;} * The Troubleshooting Process &amp; Getting Ready * Hardware Tools * Software Techniques ::: ::: {.</description>
    </item>
    
    <item>
      <title>Hollywood doesn&#39;t understand software</title>
      <link>http://www.broadtechsm.com/2017/05/14/hollywood-doesnt-understand-software.html</link>
      <pubDate>Sun, 14 May 2017 17:58:39 -0400</pubDate>
      
      <guid>http://www.broadtechsm.com/2017/05/14/hollywood-doesnt-understand-software.html</guid>
      <description>&lt;p&gt;If this is our public facing image, what are our internal development efforts like?&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>What it&#39;s Like to be a Network Engineer</title>
      <link>http://www.broadtechsm.com/2017/05/11/what-its-like-to-be-a-network-engineer.html</link>
      <pubDate>Thu, 11 May 2017 20:18:05 -0400</pubDate>
      
      <guid>http://www.broadtechsm.com/2017/05/11/what-its-like-to-be-a-network-engineer.html</guid>
      <description>&lt;p&gt;Broadcast engineers can relate!&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>NTP Guide Now Available</title>
      <link>http://www.broadtechsm.com/2017/04/09/ntp-guide-now-available.html</link>
      <pubDate>Sun, 09 Apr 2017 14:37:29 -0400</pubDate>
      
      <guid>http://www.broadtechsm.com/2017/04/09/ntp-guide-now-available.html</guid>
      <description>Broadcast engineers and media IT professionals, are you wondering if you have set up NTP properly on your servers and other devices? Take a look at my guide to NTP Best Practices in a Broadcast Facility for some practical advice.</description>
    </item>
    
    <item>
      <title>NTP Best Practices in a Broadcast Facility</title>
      <link>http://www.broadtechsm.com/guides/ntp-best-practices/</link>
      <pubDate>Sun, 09 Apr 2017 14:15:00 -0400</pubDate>
      
      <guid>http://www.broadtechsm.com/guides/ntp-best-practices/</guid>
      <description>Network Time Protocol (NTP) is still the best way to synchronize computer clocks for non-real-time applications. For real-time synchronization, time code and, increasingly, Precision Time Protocol (PTP), are more appropriate. Even if you are using time code or PTP, your servers usually don&amp;rsquo;t synchronize their clocks to those signals. Because of the heavy reliance on synchronization in media applications, you need to be sure to deploy NTP properly. Fortunately, most media facilities are already in a good position to reliably use NTP because of their time code infrastructures.</description>
    </item>
    
    <item>
      <title>Decision Making Partnerships</title>
      <link>http://www.broadtechsm.com/2013/07/28/decision-making-partnerships.html</link>
      <pubDate>Sun, 28 Jul 2013 14:52:00 -0400</pubDate>
      
      <guid>http://www.broadtechsm.com/2013/07/28/decision-making-partnerships.html</guid>
      <description>&lt;p&gt;Joe Zaller at Devoncroft examines who broadcast hardware and software vendors think is &lt;a href=&#34;http://blog.devoncroft.com/2013/07/12/when-will-broadcast-engineers-be-replaced-as-key-decision-makers/&#34;&gt;the most important decision maker&lt;/a&gt; at their customers. Broadcast engineers remain the most important perceived decision maker, but vendors still predict that our importance will decrease over time. The only thing is that vendors have been making that same prediction for years.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Before Testing Resiliency</title>
      <link>http://www.broadtechsm.com/2013/07/07/before-testing-resiliency.html</link>
      <pubDate>Sun, 07 Jul 2013 19:00:00 -0400</pubDate>
      
      <guid>http://www.broadtechsm.com/2013/07/07/before-testing-resiliency.html</guid>
      <description>In Big Data/Web Scale website operations, resiliency testing is getting a lot of attention with updated methods. Yes, traditional software unit and integration testing are still key to developing reliable software. A growing number of companies taking a more active approach to testing resiliency. They actually induce failures that test a live system’s reaction. Amazon, Google, and Etsy use GameDay exercises. Netflix employs a Simian Army.
I can see the reaction of most broadcasting managers if you were to propose GameDay testing an air chain.</description>
    </item>
    
    <item>
      <title>The Wrong Broadcast Engineering Questions</title>
      <link>http://www.broadtechsm.com/2013/06/25/wrong-broadcast-engineering-questions.html</link>
      <pubDate>Tue, 25 Jun 2013 18:39:00 -0400</pubDate>
      
      <guid>http://www.broadtechsm.com/2013/06/25/wrong-broadcast-engineering-questions.html</guid>
      <description>As technologists and engineers, are we asking or answering the wrong questions about our new or potential systems too often? These wrong questions fall into different categories, but they all have right questions or, even better, statements that you or your customers can use to replace them. Here are two that have reached pet-peeve levels for me.
&amp;ldquo;What does the product do?&amp;rdquo; When an operations or other business customer asks this question, they focus on the technology and not the business.</description>
    </item>
    
    <item>
      <title>It&#39;s Still Difficult for IT</title>
      <link>http://www.broadtechsm.com/2011/01/15/its-still-difficult-for-it.html</link>
      <pubDate>Sat, 15 Jan 2011 15:08:00 -0500</pubDate>
      
      <guid>http://www.broadtechsm.com/2011/01/15/its-still-difficult-for-it.html</guid>
      <description>&lt;p&gt;Despite the fact that the IT industry is light years ahead of Broadcast Engineering in implementing service management processes and general governance, individual IT departments still experience resistance. Reichental relays recent experience with the &lt;a href=&#34;http://radar.oreilly.com/2011/01/why-is-it-governance-so-diffic.html&#34;&gt;difficulties in putting a governance program in place&lt;/a&gt; at O&amp;rsquo;Reilly Media. When you read through the article, try substituting Engineering every time he says IT.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Overhead in Ingest Channel Capacity Planning</title>
      <link>http://www.broadtechsm.com/2010/11/14/overhead-in-ingest-capacity-planning.html</link>
      <pubDate>Sun, 14 Nov 2010 18:25:00 -0500</pubDate>
      
      <guid>http://www.broadtechsm.com/2010/11/14/overhead-in-ingest-capacity-planning.html</guid>
      <description>&lt;p&gt;Millsap’s ACM Queue article on &lt;a href=&#34;http://queue.acm.org/detail.cfm?id=1854041&#34;&gt;performance tuning&lt;/a&gt; introduced me to some basics of queuing theory. The article discusses some considerations for tuning the performance of a database. One aspect that Millsap addresses is queuing delay, or the amount of time it takes for a system to begin processing a request. This is the amount of time the request waits in the queue before the system acts on it. As utilization of the system increases, the delay increases. A request needs to wait until more things in front finish.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Network Troubleshooting Guide Now Available</title>
      <link>http://www.broadtechsm.com/2009/12/14/network-troubleshooting-guide-now-available.html</link>
      <pubDate>Thu, 24 Dec 2009 15:48:00 -0500</pubDate>
      
      <guid>http://www.broadtechsm.com/2009/12/14/network-troubleshooting-guide-now-available.html</guid>
      <description>A Broadcast Engineer&amp;rsquo;s Guide to Troubleshooting a Network Problem is now available. I based it on a training presentation I&amp;rsquo;ve used in the past. I&amp;rsquo;ve tried to do my best to adapt the presentation format into a static document.</description>
    </item>
    
    <item>
      <title>A Few Words About Processes</title>
      <link>http://www.broadtechsm.com/2009/12/15/few-words-about-processes.html</link>
      <pubDate>Tue, 15 Dec 2009 20:42:00 -0500</pubDate>
      
      <guid>http://www.broadtechsm.com/2009/12/15/few-words-about-processes.html</guid>
      <description>&lt;p&gt;One of the big components of Service Management is defining processes for supporting technology. You set up a process for documenting changes, a process for requesting new services, a process for implementing that new service, etc…. That scares many broadcasters. We jump to the conclusion that a process is going to be some long, arduous quest for managerial approval that grinds to a halt every time we have to ask a new person for input.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>A Broadcast Engineer&#39;s Guide to Troubleshooting a Network Problem</title>
      <link>http://www.broadtechsm.com/guides/guide-troubleshooting-network-connection/</link>
      <pubDate>Sat, 28 Nov 2009 15:08:00 -0500</pubDate>
      
      <guid>http://www.broadtechsm.com/guides/guide-troubleshooting-network-connection/</guid>
      <description>Every broadcast system inevitably is now a collection of computer networks. Broadcast Maintenance technicians and engineers need at to understand at least basic, triage level LAN troubleshooting skills. This Guide introduces the concepts and techniques for troubleshooting a network problem from device perspective, generally without the assistance of the network infrastructure manager. If you do have access to the switches and routers on your network, some tasks get easier but the overall process does not change dramatically.</description>
    </item>
    
    <item>
      <title>About</title>
      <link>http://www.broadtechsm.com/about/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>http://www.broadtechsm.com/about/</guid>
      <description>About Broadcast Technology Service Management The Information Technology industry has crafted a set of management principles known as IT Service Management (ITSM) that refocus technology management on the business. It&amp;rsquo;s time broadcast and cable service engineers to stop managing technology for the sake of technology and start showing how they bring value to the business. BTSM is about merging ITSM principles and techniques with broadcaster&amp;rsquo;s technology.
About the Author Michael Liebman is a Principal Engineer at SiriusXM, where he leads the Broadcast Engineering Solutions Architecture team.</description>
    </item>
    
    
    <item>
      <title>Archive</title>
      <link>http://www.broadtechsm.com/archive/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>http://www.broadtechsm.com/archive/</guid>
      <description>View Posts by Year
View Posts by Topic</description>
    </item>
    
    <item>
      <title>Legal Information</title>
      <link>http://www.broadtechsm.com/legal-information/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>http://www.broadtechsm.com/legal-information/</guid>
      <description>Copyright This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Affiliation This site is not affiliated with SiriusXM Satellite Radio, Yangaroo, Fox News Media, Imagine Communications, or Viacom/MTV Networks. The opinions expressed here are those of the author and not his employer.</description>
    </item>
    
  </channel>
</rss>
