US12519710B2

US12519710B2 - Media stream monitoring

Info

Publication number: US12519710B2
Application number: US18/237,610
Authority: US
Inventors: Jack Curtis Viers
Original assignee: iHeartMedia Management Services Inc
Current assignee: iHeartMedia Management Services Inc
Priority date: 2009-12-29
Filing date: 2023-08-24
Publication date: 2026-01-06
Anticipated expiration: 2029-12-29
Also published as: US20220116298A1; US20160337220A1; US20200396149A1; US20230155908A1; US11563661B2; US20110161513A1; US11777825B2; US11218392B2; US20230396524A1; US10171324B2; US20190089612A1; US9401813B2; US10771362B2

Abstract

A stream monitor device includes at least one processor configured to implement a get stream module, which obtains, from a streaming server, stream records associated with media streams to be monitored. The at least one processor is further configured to implement a stream monitor module configured to perform event-driven monitoring of monitored media streams. The at least one processor is further configured to implement a graphical user interface (GUI) module that generates displays related to a status of the monitored media streams.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present U.S. Utility Patent Application claims priority pursuant to 35 U.S.C. § 120 as a continuation of U.S. Utility application Ser. No. 18/098,870 entitled “Media Stream Monitoring,” filed Jan. 19, 2023, which is a continuation of U.S. Utility application Ser. No. 17/558,999 entitled “Data Stream Test Restart,” filed Dec. 22, 2021, now U.S. Pat. No. 11,563,661 issued on Jan. 24, 2023, which is a continuation of U.S. Utility application Ser. No. 17/007,934 entitled “Media Stream Monitor with Heartbeat Timer,” filed Aug. 31, 2020, now U.S. Pat. No. 11,218,392 issued on Jan. 4, 2022, which is a continuation of U.S. Utility application Ser. No. 16/196,627 entitled “Media Stream Monitor,” filed Nov. 20, 2018, now U.S. Pat. No. 10,771,362 issued on Sep. 8, 2020, which is a continuation of U.S. Utility application Ser. No. 15/218,113 entitled “Media Stream Monitor,” filed Jul. 25, 2016, now U.S. Pat. No. 10,171,324 issued on Jan. 1, 2019, which is a continuation of U.S. Utility application Ser. No. 12/648,806 entitled “Media Stream Monitor,” filed Dec. 29, 2009, now U.S. Pat. No. 9,401,813 issued on Jul. 26, 2016, all of which are hereby incorporated herein by reference in their entirety and made part of the present U.S. Utility Patent Application for all purposes.

FIELD

The present disclosure relates generally to streaming media, and more particularly to monitoring media streams.

BACKGROUND

There are currently a number of different technologies available for monitoring media streams. One type of stream monitoring involves users physically observing a media stream using a streaming player application. The observers may be Customer Service users, in which case they can report problems to a service department, but problem identification based on observation can be sporadic and unreliable. In some cases, the observers may be trained Quality Assurance personnel, which can improve the reliability of the monitoring, but it can still be difficult to pinpoint the source of identified problems.

A second type of stream monitoring is referred to as Single Stream Monitoring. In Single Stream Monitoring, a single application is dedicated to monitoring a single stream resource. All information required to connect to the stream is generally hard-coded into the application. Client-side monitoring, which involves a monitoring module built into an end-user client application, is a third option.

Each of these technologies provides limited stream monitoring capabilities. Some are limited to monitoring a small subset of available streaming protocols and formats, while others may not provide the ability to monitor all important aspects of a stream. It is apparent, therefore, that currently available stream monitoring technologies are less than perfect.

SUMMARY

A method according to various embodiments includes receiving a multiple stream records associated with media streams being served by a stream server, concurrently testing multiple streams of the first plurality of media streams for streaming errors, and reporting a result of the testing for each of the first plurality of media streams. In some embodiments this and other methods can be implemented by executing a program instruction in a computer system.

Testing of individual media streams can be discontinued in response either an error associated with the media stream being detected, or it may continue until the media stream connects and broadcasts metadata. In some embodiments, in response to testing of the media streams being completed, stream records are removed from memory, and a second batch of stream records associated with other media streams being served by the stream server are received for testing.

Some methods include attempting to establish concurrent connections to multiple media streams, based on information included in stream records. Testing the media streams can include generating programming events indicating a status of each of the individual media streams, and providing those programming events to one or more program event handlers.

A system according to some embodiments includes a processor, memory operably associated with the processor, and a program of instructions configured to be stored in the memory and executed by the processor. The program of instructions can include instructions configured to implement various stream monitoring processes and methods described herein. Various embodiments can take the form of a computer readable medium tangibly embodying a program of computer executable instructions.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of this disclosure will become apparent upon reading the following detailed description and upon reference to the accompanying drawings, in which like references may indicate similar elements:

FIG. 1 is a block diagram illustrating a broadcasting system including a stream monitor according to various embodiments of the present disclosure;

FIG. 2 is a block diagram illustrating a broadcast chain including a stream monitor according to various embodiments of the present disclosure;

FIG. 3 is a flow chart illustrating a method according to various embodiments of the present disclosure; and

FIG. 4 is a high level block diagram of a processing system according to embodiments of the present disclosure.

DETAILED DESCRIPTION

The following is a description of embodiments of the disclosure depicted in the accompanying drawings. The embodiments are presented in sufficient detail to clearly communicate the disclosure to one of ordinary skill in the art. However, the amount of detail offered is not intended to limit the anticipated variations of embodiments; on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims.

It is often desirable to monitor broadcast content at various points and times to ensure that the intended broadcast content is being properly transmitted to audience. It is usually readily apparent to many people if there are problems with an On-Air broadcast, but the same is not necessarily true of streaming broadcasts, because each individual broadcast stream is often observed by significantly fewer audience members.

Referring to FIG. 1 , a system 100 configured to provide monitoring of individual broadcast streams according to various embodiments of the present disclosure will be discussed. System 100 includes media automation system 110, which can be used to control and automate various media broadcast functions; and traffic and billing system 120, which is used to provide control for various traffic and billing functions such as entering and editing orders, and scheduling spots. System 100 also includes streaming broadcast chain 160, through which a streaming broadcast of media content can be provided to a network such as Internet 161; on air broadcast chain 150, through which media content can be broadcast via a broadcast tower 151 or otherwise; and various media sources such as an individual source media 142, bulk media storage 141, programming from another market received via network 140, and programming broadcast via satellite 131 received via satellite receiver 130. System 100 also includes stream monitor 162, which can be used to monitor streams generated by streaming broadcast chain 160 for delivery to end users via Internet 161 or otherwise.

Stream monitor 162 can be used in various embodiments to test multiple streams generated by streaming broadcast chain 160 asynchronously and concurrently—and does not require testing media streams one at a time, and in sequence. Various embodiments of stream monitor 162 can be used to provide more nearly real time monitoring and reporting of media stream errors, and can be used to provide a visual display of the monitored metrics. In addition, various embodiments of stream monitor 162 do not require separate instances of a monitoring software module to monitor each individual stream. Instead, some embodiments permit multiple streams to be monitored concurrently using only a single instance of a stream monitor software module.

Furthermore, various embodiments of stream monitor 162 allow dynamic configuration of monitoring parameters, and monitoring a stream only as long as necessary, for example until errors are found, or until a monitored stream is confirmed to be successfully connected without silence or metadata errors.

Referring next to FIG. 2 , a broadcast chain 200 including a stream monitor 280 will be discussed according to various embodiments of the present disclosure. Broadcast chain 200 includes media processing server 210, which generates a primary stream of content for broadcast and delivers the primary stream to encoding unit 220, where the stream can be encoded into any of various streaming formats for delivery to streaming server 230. Broadcast chain 200 also includes streaming server 230, which receives the encoded stream and provides multiple individual streams, for example media streams 232, 234, and 236, to various requestors. In at least one embodiment, media streams 232 and 234 are delivered to different end users via network 240, and media stream 236 is delivered to media provider 250, which may rebroadcast all or a portion of the media content included in media stream 236.

As is well known by those of skill in the art of streaming media, multiple end users or other entities can request to connect to streaming server 230. Once a connection is established, streaming server 230 can transmit packetized media content in individual media streams to each of the requestors over separate network connections. Streaming media players, for example streaming video or audio players, receive, decode, and play the media content at the requestors' locations.

The media streams 232, 234, and 236 which are streamed to the requestors may include both media content and metadata associated with the media content of the media streams. For example, each media stream may include a song or other audio content, while the metadata includes various information about the song such as a title, author, artist performing the song, related concert events, or other desired information. The metadata can be used to generate displays or perform other functions on a computer running the streaming media player.

Broadcast chain 200 also includes stream monitor 280, which can include get stream module 282 for requesting stream records from streaming server 230; graphical user interface (GUI) host 285, for hosting GUI module 287; GUI module 287, for generating and preparing displays related to the status of the streams in the system currently being monitored; display 270, for displaying a GUI generated by GUI module 287; stream monitor host 284, to host stream monitor module 286; and stream monitor module 286, for performing event driven monitoring of media streams associated with stream records obtained by get stream module 282.

Get streams module 282 can be configured to communicate with streaming server 230 to request stream records associated with each of the media streams 232, 234, and 236. When the stream records are received, stream monitor module 286 can individually and concurrently monitor each of the media streams 232, 234, and 236 for connection errors, media content errors, metadata errors, or other errors related to a media stream being served by streaming server 230. In some embodiments, once all media streams have completed their individual tests, the streams are disconnected, and additional stream records are requested.

Stream monitor module 286 can deliver testing results to a display device, such as display 270, via GUI 287. Additionally or alternatively, stream monitor module 286 can deliver the results for storage in memcache servers (not illustrated), database 260, or elsewhere. In various embodiments, stream monitor module 286 can provide error or success notifications on a stream by stream basis, immediately upon completion of testing for an individual stream. In other embodiments, testing results are reported after testing of an entire batch of streams indicated in the streaming records received from streaming server 230.

Successful streams can be reported in an asynchronous Hypertext Transfer Protocol (HTTP) request, in response to which previous errors reported by a successful stream can removed from the database, memcache servers, or elsewhere. In some embodiments, all stream records received by get stream module 282 are also removed from system memory upon completion of testing all media streams associated with received stream records. A new set of streams beginning at the last stream record received and ending at a configurable amount of stream records to be monitored concurrently can be asynchronously requested from the same streaming server 230, and the process can repeat itself until the stream monitor application is shut down.

In some embodiments, get stream module 282 can request a designated number of stream records based on a number of individual streams that stream monitor module 286 can test at any one time. In various embodiments, the number of streams requested is configurable by a user, and may be based on anticipated system loads and resources. In some embodiments, a beginning or ending stream record can also be set.

In the illustrated embodiment, stream monitor 280 is shown as a standalone computing device running various event-driven software modules, e.g. get streams module 282, graphical user interface (GUI) host 285, GUI module 287, stream monitor host 284, and stream monitor module 286. Stream monitor 280 can, in some cases, be implemented in another device, for example media processing server 210 or streaming server 230. In some embodiments, stream monitor 280 may be a software program, or can include some combination of software, firmware, or hardware. In at least one embodiment, a stream monitor 280 can be implemented as a set of web pages serving specifically formatted extensible markup language (XML) pages, whether generated via a dynamic scripting language, or created by hand and served via proxy through a dynamic scripting language (the query parameters should be parsed to get the correct records back).

Referring next to FIG. 3 , a method 300 of concurrently monitoring multiple media streams will be discussed according to various embodiments. Method 300 begins at block 305. As illustrated by block 307, a number of media streams to concurrently monitor for errors can be set. The number of streams to be concurrently processed can be set automatically or manually, based on system resources, or as otherwise desired.

As illustrated by block 309, a media stream monitoring program can send a request to a streaming server for stream records. In some embodiments, the media stream monitoring program can be implemented as a webpage that requests stream records from a stream manager database, and builds the XML return. The stream records for each media stream can include, but are not limited to, the following: the protocol to use to connect to the stream; the URL used to connect to the stream; the path on the streaming server to the stream; the host name of the host hosting this stream on the streaming server; the stream title for this stream; the sited associated with this stream; the station associated with the stream; description—the stream type description of the stream; the type of URL for this stream; the unique id number for the stream; a secured hash token used to connect to the stream; and the total number of stream records available in the system.

In some embodiments, the request can be used to pass an integer value startAt, which indicates the stream record number at which to begin retrieving stream records, and an integer value limit, which is the total number of records to retrieve and can correspond to the number of streams set at block 307.

As illustrated by block 311, the stream monitor attempts to establish connections with the media streams referenced in the stream records. Connection attempts to multiple media streams can be made using information included in the stream records. In at least one embodiment, connecting to a stream records means that packets included in a stream being served to an end user are sampled, read, intercepted, or otherwise accessed.

As illustrated by block 313, a check can be made to determine if one or more of the streams did not connect. In addition to testing for connection errors, media streams can also be checked for silence or amplitude errors, metadata errors, and other types of errors. As illustrated by block 315, if no errors are detected for a particular media stream, method 300 checks to determine if the stream successfully connects and begins to send metadata. If the media stream being monitored has not yet successfully connected and streamed metadata, method 300 continues to check for errors as illustrated by block 313.

As illustrated by block 317, testing of each individual media stream continues until either an error occurs, or the media stream connects and streams metadata, at which point testing of the stream is discontinued, and the results are reported. In some embodiments, errors may not be reported until all of the media streams being concurrently tested experience an error or connect and successfully send metadata.

As illustrated by block 319, when testing of a particular media stream has completed, a check can be made to determine if testing is complete for all, or a designated number, of media streams being concurrently tested. If all streams are not done testing, the testing of the remaining streams can continue.

If there are large numbers of total streams to be monitored keeping track of the last tested record is advantageous. Thus, in at least some embodiments, a configurable lastRecord integer is used in the event of a failure to notify a stream monitor of a starting stream. The lastRecord integer also allows a stream monitor to chunk large numbers of streams into a single testing round or batch.

The lastRecord integer can be delivered in conjunction with a “heartbeat” signal, which is used to send a JavaScript message to a hosting web page of the application periodically. The hosting web page, for example, may expect a heartbeat signal every second, and if one doesn't come, the lastRecord integer can be used to re start the stream monitoring application from where it left off. Some embodiments do not use a heartbeat signal. For example, various desktop implementations can write a limit and last record to a file, which can be copied and checked periodically to ensure that the value is still changing.

In some embodiments, the lastRecord can also be used to keep track of where the application is at in relation to the total number of streams the application is monitoring. So, for example, once the total streams tested is equal to the total number of streams to test, the application resets lastRecord to zero and begins to test all the streams again.

As illustrated by block 321, if testing has been completed for all of the media streams being concurrently tested, the stream records can be removed from memory, and a new request for stream records can be sent as illustrated by block 309.

In various embodiments, method 300 is implemented using an event-driven architecture. Events are specific moments in application execution that are subscribed/listened to by zero or more objects, triggering those objects to execute some action. Using an event-driven architecture allows various methods to be private, internal, or protected members of a listener object. Additionally, event handlers can be polymorphic, and overridden or inherited by child classes.

A potential advantage of using an event-based architecture for determining whether or not stream errors have occurred is that several listener objects can respond to the same event at roughly the same time without interfering with each other, thereby allowing a synchronous program to run asynchronously. Furthermore, code maintenance can be simplified. Events can be broadcast without consideration of whether callbacks are subscribed or exist. Different classes can listen to the same event and behave in different ways than other event handlers, and dispatch event need not be deleted in the dispatching object, because actions are only executed if anything is listening to the event.

Some events that can be generated by a stream monitor application to facilitate testing for stream errors include the following:

- mx.events.FlexEvent.CREATION_COMPLETE—triggers application script execution after the application is finished building.
- com.cc.BaseViewEvent.DATA_READY—triggers application actions that are dependent upon the view elements being created. In this case, begins testing execution in the TestStreamMetadataController object.
- TestStreamMetadataController._pingTimer-TimerEvent.TIMER_COMPLETE event: triggers the sending of a “heartbeat” to the application host container, indicating that the flash VM is still running.
- TestStreamMetadataController._streamApi-StreamApiEvent.STREAM_DO_CREATED event: triggered when a xml entity retrieved from the webserver has been converted into a StreamDo data object. The data object is sent as a property of the event object.
- mx.rpc.events.ResultEvent.RESULT event: data from the http request has been received. Triggers the StreamApi.resultEventHandler in this application.
- com.ak.events.AkErrorEvent.ERROR event: there has been an error on the stream associated with the event target. Depending on the errors error number, a stream connection error may be posted.
- com.ak.events.AkStatusEvent.NETSTREAM_METADATA event: a stream has metadata to report via the connection.
  The com.cc.controller.TestStreamMetadata.metadataHandler method listens for this event and uses the information passed in it to determine if the metadata is valid. Failure to send this event or invalid or empty fields within this event can cause a metadata error to be reported.
- com.ak.events.AkStatusEvent.“onUDPData” event: A non-orban card encoded stream has metadata to report via the connection.
  The com.cc.controller.TestStreamMetadata.metadataHandler method listens for this event and uses the information passed in it to determine if the metadata is valid. Failure to send this event or invalid or empty fields within this event on non-orban card encoded streams causes a metadata error to be reported.
- Com.ak.events.AkNotificationEvent.CONNECTED event: indicates that the stream has connected to the host and can attempt to play the file requested.
- Com.ak.events.AkStatusEvent.NETSTREAM event: indicates a change in the connection associated with a streamDo has changed status. Netstream events with “Netstream.Play.Start” info.code properties indicate a true successful connection to a stream and trigger the streamDo.connected property to be set to true. Other status messages can be ignored or cause a stream connection error to be reported.
- Com.ak.events.AkStatusEvent.NETSTREAM_PLAYSTATUS: indicates that a stream on a connection associated with a particular streamDo has completed or changed to a different stream. Since the radio streams can be set to run all the time, this may indicate a connection error.
- Com.cc.events.api.StreamApiEvent.REQUEST_RECEIVED: indicates that a request sent by the StreamApi has received a response.
- Com.cc.events.api.StreamApiEvent.FAULT: indicates that the StreamApi request has failed.
- Com.cc.events.api.StreamApiEvent.STREAM_DO_CREATED: indicates that a StreamDo object has been created from the StreamApi request result.

An event-driven architecture also includes event handlers, which respond to events. A single event can trigger several event handlers. An event handler typically accepts a single event class type, or children of an event type. It is possible to assign an event handler for every event type of a given event class, but typically a separate event handler is assigned for each event type in an event class. A stream monitor application according to some embodiments follows this practice. The following is a list of some event handlers, with the event classes and types that they accept:

- com.cc.api.StreamApi.resultEventHandler-mx.rpc.events.ResultEvent.RESULT: handles the result of the server request, in this case converting each xml entity stream record into a com.cc.dO.StreamDo object, firing a com.cc.events.api.StreamApiEvent.STREAM_DO_CREATED event containing the created StreamDo object, initiating testing of the streams.
- Com.cc.controller.TestStreamMetadataController.streamApiDoCreatedHandler—com.cc.events.api.StreamApiEvent.STREAM_DO_CREATED: handles the event that is fired when a StreamDo is created from a StreamApi request. Sets up the streamDo's connection, the connection's event handlers, the streamDo's test timer, and the testing variables, initializing the test by calling the connection's connect method.
- Com.cc.controller.TestStreamMetadataController.connectedHandler-com.ak.events.AkNotificationEvent.CONNECTED: begins playback of the streamDo's stream.
- Com.cc.controller.TestStreamMetadataController.errorHandler-com.ak.events.AkErrorEvent.ERROR: Handles any error event broadcast by the connection. Nearly every error event triggers a connection error to be posted.
- Com.cc.controller.TestStreamMetadataController.streamPlayStatusHandler-com.ak.events.AkStatusEvent.NETSTREAM_PLAYSTATUS: handles stream events related to the play status, including the original NetStream.Play code indicating that the streamDo's connection has successfully connected to the stream.
- Com.cc.controller.TestStreamMetadataController.metadataHandler-com.ak.events.AkStatusEvent.NETSTREAM_METADATA: Handles any metadata events issued by streams that are ORBAN sound card encoded. Checks to see that all the information required exists in the metadata event issued by the streamDo's connection. If the information doesn't exist, issues a metadata error report to the server. If the encoding information is an ORBAN encoded stream, completes the test for the streamDo instance by calling testComplete.
- Com.cc.controller.Test StreamMetadataController.udpHandler-com.ak.events.AkStatusEvent.onUDPData: similar to the Metadata handler, handles metadata from streamDos' connections when the stream is NOT encoded by an ORBAN sound card. When this is triggered, the test is completed. In some embodiments, this handler will issue an error report if metadata criteria are not fulfilled.

The monitor application's com.cc.api.StreamApi.getFlashStreamsByLimit method accepts the lastRecord and the total number of streams to fetch at one time. As the monitor application cycles through each round, eventually there will be a small number of streams left. The application then only requests the remaining number of streams to keep from doubly testing streams when the application starts over from record 0.

A particular embodiment of method 300 begins with a host web page initializing a stream monitoring application. Once all the components are loaded and rendered, a creationComplete event triggers the instantiation of a com.cc.view.TestStreamMetadataView, passing the application as a parameter.

The view creates a com.cc.controller.TestStreamMetadataController instance, adds listeners for the controller's clearText, error, and info events, then dispatches a dataReady event, indicating that it is ready to display data.

When the controller is instantiated, it stores a reference to the view. Then it stores the lastRecord parameter passed to the application. It registers baseViewEventDataReady as the event handler for the view's dataReady event, initializes the application heartbeat _pingTimer timer, and adds listeners for its TimerEvent.TIMER event to send a JavaScript notification to the hosting web page. Then it starts the _pingTimer.

The _pingTimer fires every second, sending _lastRecord to the hosting web page. If the application fails, the _pingTimer heartbeat won't fire, and the application will be restarted by the host web page.

After the view dispatches its dataReady event, the event is caught by the controller's baseViewEventDataReady handler. The controller's testStreams and totalTestStreams are set to zero. The StreamApi instance is instantiated, and streamApiDoCreatedHandler is registered to listen for the com.cc.events.api.StreamApiEvent.STREAM_DO_CREATED event, which will happen once for every record received. Then the StreamApi's getFlashStreamsByLimit method is called, initializing testing.

The getFlashStreamsByLimit disconnects the _flashStreamingService mx.rpc.http.HTTPService instance, clears any previous result, sets the service's URL property to the xml location, sets the service's resultFormat to e4x, sets the param object's startAt to the last parameter and sets params object's limit property to the limit parameter passed when the getFlashStreamsByLimit method was called. The previous event listeners are then removed from the service, and re-added. This reduces memory leak potential. Then the request is sent to the service's URL, passing the params object as GET variable name value pairs.

If the service fails, a mx.rpc.http.HTTPService.fault event is dispatched and caught by the StreamApi's faultEventHandler method. The service's faulEventHandler is removed so that it doesn't fire twice, and the StreamApi dispatches an event notifying of the failure.

If the service is successful, a mx.rpc.http.HTTPService.result event is dispatched and caught by the StreamApi's resultEventHandler method. This method increases the StreamApi::_requestNumber property by 1, removes the result event listener to prevent it from firing twice, converts the result string to an XML document and stores it in a local method variable. The number of records returned in the request is the number of children of the XML document. If there are multiple records, the children are looped through, and each record's properties are stored on a new StreamDo object and dispatched with a StreamApi.StreamApistreamDoCreated event. If there is only one record, that record is converted to a stream Do object and dispatched with a StreamApi. StreamApistreamDoCreated event. If the result contains no records, the total amount of streams has been exceeded by the limit and startAt parameters passed to StreamApi::getStreamsByLimit, so the getStreamsByLimit is called again with 0 as startAt and 50 as limit to start the next testing round, thus making the algorithm self-sustaining.

When each STREAM_DO_CREATED event is dispatched, it is caught by the controller's streamApiDoCreatedHandler. After the connection is created, the stream monitor creates a metadata timeout timer. This timer is the master timeout, killing the test and logging the appropriate error after a period of 35000 milliseconds if the stream hasn't connected or received metadata. The controller's _recordsExpected is set to the event's streamDo.streamsExpected property minus 1. The controller's _streamsToTest is set to the event's streamDo.testStreams property. The controller's _lastRecord is incremented by 1. The metadata timer is added to the streamDo, and an event listener for the timer's timer complete event is added to the timer. TestComplete, connected, and metadataSuccess are set to false and added to the streamDo. The Ak connection is added to the streamDo. Event listeners for the above listed interesting com.ak.events events are added to the connection, and the connection's maxBufferLength is set to 5 seconds, and its live StreamMasterTimeout to 15 seconds. The buffer length can be used to limit the amount of memory a stream is allowed to use, and the master timeout can be used to prevent a stream from trying to connect forever. If a stream takes longer than 15 seconds to connect, the connection is assumed to have failed. The metadataTimer is started and the connection's connect method is called.

If the connect method works, the connection dispatches a connected event. This does not necessarily mean that the stream itself will play or is truly connected. It means that the hosting application on the flash media server was found. The streamDo containing the connection is not set connected to true until a NETSTREAM_PLAYSTAUS event with Netstream.Play.Start info code is dispatched by the connection.

Any errors dispatched by the connection are handled by the controller's errorHandler. If it is an error related to the connection, a connection error is reported via the StreamPostApi's sendConnectionError method.

The connection test for a single stream can be considered to be complete when NETSTREAM_PLAYSTATUS event with an info.code property of NetStream.Play. Start occurs.

The metadata test (for a single stream) can be considered to be complete when a NETSTREAM_METADATA or a onUDPData event is dispatched with all the required information in the metadata object. If the information is invalid, a metadata error is reported by StreamPostApi via sendMetadataError. If the metadata is valid, the streamDo's metadataSuccess variable is set to true, testComplete is called, stopping the streamDo's metadata timer, incrementing the number of tests complete, removing event listeners from the streamDo, and checking to see if all the tests for this round have completed using testingRoundComplete.

If the metadata timer for a streamDo completes and connected is true, a metadata error is posted and testComplete is called.

TestingRoundComplete checks to see if _testStreams is greater than or equal to _recordsExpected. If it is, the round of testing is completed and the streams are looped through. Each stream that connected and had metadata is sent to the server (in a comma separated string), identified by streamId number. Each stream is stripped of event listeners. Each stream's connection is closed and unsubscribed, and the metadata timers reset. A wait of ten seconds is started to give the garbage collector time to clean up, then finshRound is called.

In finishRound, the controller is reset to receive the next round of stream records. All the old streams are cleared out and replaced by a blank _streams array. _successStreamIds is also cleared and reset. If _totalTestsComplete is greater than or equal _streamsToTest minus 1, all the streams have been tested and the monitor should start over at stream 0, so _lastRecord and _totalTestsComplete are set to 0. Otherwise, they remain as they were. Then the monitor waits for 20 seconds to allow the garbage collector to do its job, then getNextStreams is called, firing a new request for stream records by StreamApi and starting the next round of testing.

Referring next to FIG. 4 , a high-level block diagram of a processing system is illustrated and discussed. Processing system 400 includes one or more central processing units, such as CPU A 405 and CPU B 407, which may be conventional microprocessors interconnected with various other units via at least one system bus 410. CPU A 405 and CPU B 407 may be separate cores of an individual, multi-core processor, or individual processors connected via a specialized bus 411. In some embodiments, CPU A 405 or CPU B 407 may be a specialized processor, such as a graphics processor, other co-processor, or the like.

Processing system 400 includes random access memory (RAM) 420; read-only memory (ROM) 415, wherein the ROM 415 could also be erasable programmable read-only memory (EPROM) or electrically erasable programmable read-only memory (EEPROM); and input/output (I/O) adapter 425, for connecting peripheral devices such as disk units 430, optical drive 436, or tape drive 437 to system bus 410; a user interface adapter 440 for connecting keyboard 445, mouse 450, speaker 455, microphone 460, or other user interface devices to system bus 410; communications adapter 465 for connecting processing system 400 to an information network such as the Internet or any of various local area networks, wide area networks, telephone networks, or the like; and display adapter 470 for connecting system bus 410 to a display device such as monitor 475. Mouse 450 has a series of buttons 480, 485 and may be used to control a cursor shown on monitor 475.

It will be understood that processing system 400 may include other suitable data processing systems without departing from the scope of the present disclosure. For example, processing system 400 may include bulk storage and cache memories, which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Various disclosed embodiments can be implemented in hardware, software, or a combination containing both hardware and software elements. In one or more embodiments, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. Some embodiments may be realized as a computer program product, and may be implemented as a computer-usable or computer-readable medium embodying program code for use by, or in connection with, a computer, a processor, or other suitable instruction execution system.

For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, or transport the program for use by or in connection with an instruction execution system, apparatus, or device. By way of example, and not limitation, computer readable media may comprise any of various types of computer storage media, including volatile and non-volatile, removable and non-removable media implemented in any suitable method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer.

Various embodiments have been described for a media stream monitor. Other variations and modifications of the embodiments disclosed may be made based on the description provided, without departing from the scope of the invention as set forth in the following claims.

Claims

What is claimed is:

1. A stream monitor device comprising:

at least one processor configured to implement a get stream module configured to obtain, from a streaming server, stream records associated with media streams to be monitored, the media streams to be monitored including media streams being currently delivered to stream requestors;

the at least one processor further configured to implement a stream monitor module configured to perform event-driven monitoring of monitored media streams, the event-driven monitoring including intercepting packets included in the media streams being currently delivered to the stream requestors; and

the at least one processor further configured to implement a graphical user interface (GUI) module configured to generate displays related to a status of the monitored media streams.

2. The stream monitor device of claim 1, wherein information included in the stream records includes:

protocols to be used to connect to individual media streams.

3. The stream monitor device of claim 2, wherein the stream monitor module is further configured to:

use the information included in the stream records to connect to a plurality of the individual media streams concurrently; and

monitor the plurality of the individual media streams individually.

4. The stream monitor device of claim 1, wherein the stream monitor module is further configured to:

disconnect from a group of the monitored media streams in response to completing monitoring of all media streams in the group.

5. The stream monitor device of claim 1, wherein the stream monitor module is further configured to:

monitor the monitored media streams for at least one of the following:

connection errors, media content errors, or metadata errors.

6. The stream monitor device of claim 1, wherein the stream monitor module is further configured to:

deliver stream status notifications to a database on a per-stream basis immediately upon completion of testing of an individual media stream.

7. The stream monitor device of claim 1, wherein the stream monitor module is further configured to:

report successful streams in an asynchronous Hypertext Transfer Protocol (HTTP) request.

8. A system comprising:

a streaming server configured to transmit packetized media content in individual media streams to each of a plurality of requestors over separate network connections;

a stream monitor device configured to monitor the individual media streams to verify that broadcast content is being properly transmitted to the plurality of requestors, wherein the stream monitor device includes:

at least one processor configured to implement a get stream module configured to obtain, from the streaming server, stream records associated with media streams to be monitored, the media streams to be monitored including media streams being currently delivered to the plurality of requestors;

the at least one processor further configured to implement a stream monitor module configured to perform event-driven monitoring of monitored media streams, the event-driven monitoring including sampling packets included in the media streams being currently delivered to the plurality of requestors; and

9. The system of claim 8, wherein information included in the stream records includes one or more of:

protocols to be used to connect to the individual media streams, an address to be used to connect to the individual media streams, a host name of a host hosting the individual media streams, media stations associated with the individual media streams, stream type descriptions of the individual media streams, or tokens used to connect to the individual media streams.

10. The system of claim 9, wherein the stream monitor module is further configured to:

monitor the plurality of the individual media streams individually.

11. The system of claim 8, wherein the stream monitor module is further configured to: disconnect from a group of the monitored media streams in response to completing monitoring of all media streams in the group.

12. The system of claim 8, wherein the stream monitor module is further configured to: monitor the monitored media streams for at least one of the following: connection errors, media content errors, or metadata errors.

13. The system of claim 8, wherein the stream monitor module is further configured to: deliver stream status notifications to a database on a per-stream basis immediately upon completion of testing of an individual media stream.

14. The system of claim 8, wherein the stream monitor module is further configured to: report successful streams in an asynchronous Hypertext Transfer Protocol (HTTP) request.

15. A method comprising:

obtaining, at a stream monitor, stream records associated with media streams to be monitored, the media streams to be monitored including media streams being currently delivered to stream requestors;

connecting to the media streams using information included in the stream records;

monitoring the media streams for errors by reading packets included in the media streams being currently delivered to the stream requestors; and

reporting statuses of individual media streams of the media streams based on the monitoring.

16. The method of claim 15, wherein the information included in the stream records includes tokens used to connect to the individual media streams.

17. The method of claim 16, further comprising: connecting to a plurality of the individual media streams concurrently.

18. The method of claim 17, further comprising:

disconnecting from the plurality of the individual media streams after monitoring of the plurality of the individual media streams has been completed.

19. The method of claim 15, further comprising:

monitoring the media streams for at least one of the following: connection errors, media content errors, or metadata errors.

20. The method of claim 15, further comprising:

reporting the statuses of each of the individual media streams immediately upon completion of testing each of the individual media streams.