NPR Distribution Future Systems initiative is a massive, far-reaching project to develop and implement the next-generation distribution system of public radio. The ultimate goal of this project is the modernization of the technology behind public radio across the nation. To support this mission and bring new and exciting features to the ContentDepot, we have made a few changes. For a deeper dive into more details, click here.
- General Questions
- Receivers and Ports
- Looking Forward
What are broadcast services?
In ContentDepot, broadcast services are a new way of thinking about how stations subscribe to programs, receive episodes, and schedule content for playback and listener consumption.
A broadcast service represents a radio station's scheduled programming, intended for air to its listeners. A station may have multiple broadcast services, such as a broadcast service with a News & Talk format and another broadcast service with a Classical format. Broadcast services will serve as the “middleman” between subscriptions and receivers, and they can be assigned to multiple destinations.
How do broadcast services affect my station’s subscriptions?
Stations can now build a single schedule and have it delivered to multiple receivers or add and remove receivers without having to subscribing and unsubscribing. This is a big change from how subscriptions used to work. These subscriptions are no longer associated directly to your station’s receivers, but rather to your station’s broadcast service that has destinations assigned to it. With this change, ContentDepot makes it easier for you to move subscriptions around to different receivers and ports.
Receivers and Ports
Can a receiver port be assigned to more than one service?
No, a port can only be assigned to a single service. However, you can use the same receiver, different ports, on different broadcast services.
Instead of using two different ports for newscasts and other live programs, can I put them both on the same broadcast service?
Not yet, because this functionality doesn't exist on the IDC receivers currently being used at the stations. It is, however, a feature that we are exploring for the future system (not available at launch). Currently, if live programming were to cause a receiver port conflict, the programming would need to be placed on two separate broadcast services.
How do we change which receivers a file goes to?
File delivery is based on the receivers associated with the broadcast service you're subscribing on just like with the live content. For example, if a broadcast service is assigned the destinations receiver 1, port 1 and receiver 2, port 1, the live content and the file content will automatically go to both receivers. If a broadcast service is assigned to only one receiver, the live and file content will only be delivered to the single assigned receiver.
It is strongly recommended that you assign multiple receivers to a broadcast service if you want live or file redundancy. Unlike the legacy subscriptions, content will only be delivered to the receivers associated with the broadcast service. If you are unable to merge redundant broadcast services at this time, you must create separate subscriptions on the individual broadcast services to maintain live and file redundancy.
Does it matter which port I subscribe to to get my file shows delivered to my receiver?
Currently no, it doesn't matter which port the broadcast service is associated with for file deliveries. However, we are exploring options for file playout on the receiver in the future system (not available at launch). If that feature rolls out, the port would matter. That being said, which the particular receiver you associate with a broadcast service does affect file delivery. Live and file content will only be delivered to the receivers associated with a broadcast service. Please see the previous question for more details.
Since files are delivered to a specific port, does Depot Monitor or AudioVault Content Depot Importer know where to find these files?
All previously subscribed file programs will go to all of your receivers. This was handled during the subscription migration by creating separate file subscriptions on each migrated broadcast service. Future file subscriptions that you create will be slightly different.
If you would like to receive the files on multiple receivers you have two options: 1) subscribe to the program on a broadcast service that has multiple receivers assigned to it (recommended), OR 2) create multiple subscriptions on individual broadcast services to the same file show. Refer to the question "How do we change which receivers a file goes to?" for more information.
The files will still be delivered to the same network share on the receivers associated with the broadcast service regardless of the port assignment. Refer to the question "Does it matter which port I subscribe to to get my file shows delivered to my receiver?" for more information.
The specifics of which receiver your automation system monitors and how that monitoring handles fail-over is a per vendor, per station configuration option. This functionality is not configured or maintained in ContentDepot. However, if you assign multiple receivers to a broadcast service OR create multiple subscriptions in the future, you shouldn't need to change your current configuration.
ContentDepot had a rule that limited a program's subscription to two ports. Can, for whatever reason, a program now be assigned to more than two receiver ports?
Yes: with the introduction of broadcast services, we have removed the "two port rule" limitation.
Can I delete obsolete broadcast services without disrupting port assignments on active broadcast services?
If you are sure that a broadcast service is no longer being used on-air, yes, you can delete the broadcast service without interrupting other broadcast services. When a broadcast service is deleted, all subscriptions on the broadcast service are deleted and any associated receivers/ports are un-associated and available for use on other broadcast services. Deleting a broadcast service cannot be undone.
If you would like to be extremely cautious, you can manually un-associate all destinations on the broadcast service and rename the broadcast service to something like "Obsolete Service 1". You can then leave the broadcast service in this state for a few days to verify that there is no impact to your on-air operations. At that point you know it is safe to delete the broadcast service.
Can I set a file to be sent to an FTP server at the station instead of the receiver?
You can associate an FTP server to a broadcast service and file content will be delivered to the FTP server in addition to any other destinations associated with the broadcast service.
Are there any file name schema changes planned?
No, we currently do not have any plans to change how these files are named.
Do I have to re-subscribe to the current programs on all my streams, or will they transition automatically?
No, all of your previously subscribed programs have been migrated over to your new broadcast services.
Is it correct to say that each receiver has four Broadcast Services?
Yes: during the initial migration and creation of broadcast services, each receiver would have generated four broadcast services. We recommend review the subscription to each service, renaming them, and reducing the number of services you have.
Is there another way to set the air windows to our own time zones?
Currently, you must subscribe to content using Eastern time. We are aware of the desire to subscribe and view schedules in local time zones, and we have started some internal development around that feature, but can provide no estimated delivery date at this time.
When I click on "show file" in my broadcast service schedule I see dozens of schedule overlaps. Do these need to be cleaned up? Are they a problem?
Before the introduction of broadcast services, subscriptions only had a simple "what time of day do you play this" field that most stations left to the default of midnight. These schedule overlaps will not cause issues with you receiving your files; the files will continue to be delivered to the receivers associated to the broadcast services they are subscribed on. We recommend that stations go to each of these file shows and edit their playout times to accurately reflect when they are playing them out. This will reduce the number of overlaps that stations see in their broadcast schedules and make the schedule functionality more useful in the future.
We expected this situation at rollout which is why the "show files" option currently defaults to "off"; however, it may default to "enabled" in the future after stations have had time to update their schedule information.
Will future iterations of ContentDepot affect the NPR Program Alert Service, aka SquawkNet, which enables participating stations to air breaking news coverage while unattended?
SquawkNet will be supported in its current form with the future system. That is, we'll continue to use cues on the Breaking News program to indicate SquawkNet activation. In order for this functionality to continue to work, we recommend that stations have a dedicated broadcast service associated with the appropriate receiver port to carry only Breaking News. We are exploring other methods of supporting SquawkNet and Breaking News in the future system that may not require a dedicated port, but we don't expect any changes for the future system rollout.
What are the next steps for stations to make the most of broadcast services?
First, if you want true redundancy between ports (within a receiver or across receivers), associate both ports to the same broadcast service. This doesn't require changing subscriptions, but instead just disassociating a port from one broadcast service and associating it with another broadcast service. This assures that the exact same content, live and file, is delivered to the two receivers/ports. For example, if you want r1p1 and r2p1 to always be identical for redundancy, associate them both to the same broadcast service. Obviously we recommend doing this when the receiver/port being disassociated is not actively on-air.
Once you do this, you can then delete the migrated broadcast service you're no longer using. From that point on, whenever you modify a subscription on the broadcast service the change is applied to all associated receivers for redundancy. We explored automatically doing this merging of broadcast services but we found too many slight differences to automate it reliably, which is most likely the result of stations having to manually keep the receivers/ports in sync with old subscriptions over the years. We assume stations know better than we do which receiver/port is their primary and which they want to use as a redundant backup, so we determined that it was safer to migrate each port to a separate broadcast service and let the stations move the receiver/port assignments to match their local use cases and then delete unused, migrated broadcast services.
Second, you can edit your existing subscriptions to set accurate schedule information. This will help avoid the appearance of double bookings on your broadcast service schedule because it will slot the programming into the proper location in the schedule rather than having everything stacked up at midnight. As we mentioned in some of our previous communications to stations, content delivery timing is still following the existing rules so you can safely update your broadcast service schedule and not worry about it changing the timing of when content is delivered to your station. This may change in the future, but we will give stations notice well in advance before we make any delivery timing changes.
Is there a deadline by which stations will have to change its services from the migrated legacy configuration?
There isn't currently a deadline, so you can leave them as migrated. When the new receivers arrive, you'll just check the ports on the broadcast service to immediately start getting your live and file content on the new receiver. However, to take advantage of some of the features we expect to release after the future system rollout and to improve the reliability/redundancy of your existing receivers, we recommend you read through the answer to "What are the next steps for stations to make the most of broadcast services?" to learn how you can start making updates today.
We also recommend merging redundant broadcast services sooner rather than later to make live and file redundancy easier to maintain. The legacy services as migrated require multiple subscriptions to receive the content on multiple receivers. This can be simplified by assigning multiple receivers to the same broadcast service. Refer to the question "How do we change which receivers a file goes to?" for more information.