USRE50355E1 - Reducing unicast session duration with restart TV - Google Patents

Abstract

A first portion of programming aired prior to a first time is obtained via a unicast session with a server, the first portion including previously aired programming. When the programming data being sent via the unicast session catches up to a multicast broadcast of the programming, the unicast session is terminated and a switch is made to obtaining a remaining portion of the programming from a different source other than the server. This different source can be, for example, a local storage device or a multicast broadcast of the programming.

Description

RELATED U.S. APPLICATION DATA

This application is a reissue application of U.S. Pat. No. 10,063,934, which issued based upon U.S. patent application Ser. No. 12/277,797, which is hereby incorporated by reference herein in its entirety.

BACKGROUND

Television viewing and recording technology has been continually advancing, with hundreds of channels, digital video recorders (DVRs), and video-on-demand programs finding their way into many homes. Despite such advances, problems still remain. One such problem is that although some systems may allow different users to begin watching the same program at different times, this can result in situations where many dedicated sessions are established between a program server and each of multiple individual users' systems for the same program. This can thus result in increased resource requirements and costs for servers and other components, and thus the overall cost of the television viewing system.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

In accordance with one or more aspects, a first portion of programming aired prior to a first time is obtained via a unicast session with a server. The first portion includes previously aired programming. A switch is made, after programming data received via the unicast session catches up to a multicast broadcast of the programming, to obtaining a remaining portion of the programming from a different source other than the server.

In accordance with one or more aspects, a first portion of programming aired prior to a first time is sent to a consumer device via a unicast session with the consumer device. The first portion of programming includes previously aired programming. The unicast session is terminated after programming data sent to the consumer device via the unicast session catches up to a multicast broadcast of the programming.

BRIEF DESCRIPTION OF THE DRAWINGS

The same numbers are used throughout the drawings to reference like features.

FIG.1 illustrates an example system implementing the reducing unicast session duration with restart TV in accordance with one or more embodiments.

FIGS.2,3, and4 illustrate different examples of the reducing unicast session duration with restart TV in accordance with one or more embodiments.

FIG.5 is a flowchart illustrating an example process for reducing unicast session duration with restart TV in accordance with one or more embodiments.

FIG.6 is a flowchart illustrating another example process for reducing unicast session duration with restart TV in accordance with one or more embodiments.

FIG.7 illustrates various components of an example client device that can implement one or more embodiments of the reducing unicast session duration with restart TV.

FIG.8 illustrates an example entertainment and information system in which one or more embodiments of the reducing unicast session duration with restart TV can be implemented.

DETAILED DESCRIPTION

Reducing unicast session duration with restart TV is discussed herein. In accordance with one or more embodiments, when a user requests to have audio/video programming played back that is already being aired, the programming is transmitted to the user's device via a combination of a unicast session and a multicast broadcast. A first portion of the programming, including a portion that was broadcast prior to the user's request, is obtained by the user's device via a unicast session with a server maintaining a copy of the programming. Concurrently, the remaining portion of the programming can optionally be recorded by the user's device via the multicast broadcast. Once the data sent to the user's device via the unicast session catches up to the data in the program being currently multicast broadcast, the unicast session is terminated. The remainder of the programming can then be played back at the user's device from another source, such as from the recording on the user's device, or from the multicast broadcast.

FIG.1 illustrates anexample system100 implementing the reducing unicast session duration with restart TV in accordance with one or more embodiments.System100 includes aserver102 that can communicate with one or more (M) consumer devices104(1-M) via anetwork106. Network106 can be a variety of different networks, including the Internet, a local area network (LAN), a cellular or other wireless phone network, a public telephone network, an intranet, other public and/or proprietary networks, combinations thereof, and so forth. In one ormore embodiments network106 is implemented to include an Internet Protocol (IP)-based network that facilitates programming content distribution and data communication between theserver102 and any number ofconsumer devices104. An IP-based network is a network that supports communication among devices using IP, such as IP version 4 (IPv4, such as discussed in IETF RFC 791), as well as other versions such as IP version 6 (IPv6).

Server102 includes aunicast module112 and anetwork buffer114. Althoughserver102 is illustrated as including bothmodule112 andbuffer114, alternativelymodule112 andbuffer114 can be implemented in different servers.Server102 can be implemented as one or more computing devices. Additionally, although asingle server102 is illustrated inFIG.1, alternatively multiple servers can communicate withconsumer devices104 vianetwork106.

Generally,server102 receivesprogramming120 in the form of a multicast broadcast from one or more sources as the programming is aired by the source(s).Server102 stores the aired programming as programming data innetwork buffer114. This programming data stored inbuffer114 is then made accessible toconsumer devices104 after (and during) airing of the programming so that the programming can be obtained and played back (and/or stored) byconsumer devices104. This allows a user of adevice104 to request playback of a particular program after the program has begun airing, and have the portion of the program that has already aired transferred to thedevice104 fromnetwork buffer114. This functionality allowing playback of a program that has already begun airing is also referred to as restart TV, as it allows a user to restart playback of particular programming from the beginning of the programming (e.g., restart playback of a particular television program from the beginning of the television program).

Programming120 can also be distributed directly toconsumer devices104 vianetwork106.Programming120 is typically a multicast broadcast of programming data. A multicast broadcast refers to the transmission of programming in a one-to-many configuration, where one source can broadcast the same data to multiple recipients concurrently. Different channels carrying different programming are typically multicast broadcast by one or more sources, andindividual consumer devices104 can tune to particular channels in order to obtain the programming being broadcast on the tuned-to channel.

Programming120 includes audio and/or video programs from one or more sources, such as a satellite operator, a network television operator, a cable operator, and so forth.Programming120 can be received from the sources via a variety of different transmission media, such as satellite transmission, radio frequency transmission, cable transmission, and so forth. Optionally, a content distributor (not shown inFIG.1) receivesprogramming120 from the various sources and convertsprogramming120 into an appropriate format for a multicast broadcast vianetwork106. Alternatively, one or more sources can directly broadcastprogramming120 vianetwork106 without using such a content distributor. The airing or broadcasting of programming refers to the transmitting of the programming by a source via any transmission media.

Programming120 can include a variety of different television programs having a variety of different lengths, such as television sitcoms, news broadcasts, documentaries, cartoon shows, movies, and so forth. These programs can optionally include advertisements as well. Any program that can be aired by a source can be included as a program ofprogramming120.

Programming120 is stored innetwork buffer114. In one or more embodiments, all programs received asprogramming120 byserver102 are stored innetwork buffer114 at least temporarily. Alternatively,server102 can optionally impose one or more filters to restrict which programs are stored innetwork buffer114.Network buffer114 stores programs at least temporarily, and the duration of this temporary storage can vary. For example, the duration can be 4 hours, 48 hours, 72 hours, 1 week, and so forth. It is to be appreciated that the exact duration of this temporary storage can vary by implementation and based on the desires of an operator ofserver102.

Unicast module112 manages unicast sessions betweenconsumer devices104 via which programming stored innetwork buffer114 can be sent. A unicast session refers to a one-to-one configuration in which a dedicated communication session betweenserver102 and oneconsumer device104 is established. Programming data fromnetwork buffer114 can be sent to the oneconsumer device104 via this dedicated communication session, but no other consumer device receives the programming data via this dedicated communication session.Unicast module112 can typically manage multiple unicast sessions concurrently. However, each of these multiple unicast sessions would be to adifferent consumer device104 or would be independent unicast sessions to thesame device104, even if the same programming data were being communicated in the multiple unicast sessions.

It should be noted that each unicast session typically involves a dedicated server and also relies on having access to a particular quality of service for network path resources. An operator ofserver102 typically plans network and server capacity to meet a peak demand. This can result in significant resource needs for the unicast sessions as deployments scale to serve large numbers of users.

As discussed in more detail below,unicast module112 receives a request from aconsumer device104 for programming that is currently being aired.Unicast module112 establishes a unicast session with the requestingconsumer device104, and a portion of the program that has already been aired is sent to theconsumer device104 fromnetwork buffer114 via the unicast session. Once the data that is sent via the unicast session catches up to the data being broadcast asprogramming120,consumer device104 switches to obtaining the remaining portions of the programming from a different source. This different source could be, for example, the source ofprogramming120 asprogramming120 is being multicast broadcast, or from a local storage device of theconsumer device104 as discussed in more detail below.

Eachconsumer device104 can be a variety of different types of devices. For example, aconsumer device104 can be a desktop computer, a mobile station, an entertainment appliance, a television, a portable computer, a television set-top box, a cellular or other wireless phone, a gaming system, an automotive computer, and so forth. Thus,consumer devices104 may range from a full resource device with substantial memory and processor resources (e.g., personal computers, game consoles) to a low-resource device with limited memory and/or processing resources (e.g., traditional set-top boxes, hand-held game consoles).

Eachconsumer device104 includes aunicast module132, amulticast module134, alocal storage module136, and aprogram playback module138. It is also to be appreciated that aconsumer device104 can include multipleunicast modules132,multiple multicast modules134, multiplelocal storage modules136, and/or multipleprogram playback modules138.Unicast module132 communicates withunicast module112 ofserver102 to establish a unicast session betweenserver102 andconsumer device104.Unicast module132 also manages obtaining data from server102 (the programming data from network buffer114) via the unicast session.Unicast module132 forwards the data obtained via the unicast session to programplayback module138 for playback, and/or tolocal storage module136 for storage. In one or more embodiments,unicast module132 initiates establishing the unicast session withmodule112 in response to a user request received atconsumer device104 for a particular program to be played back and/or recorded, as discussed in more detail below.

Multicast module134 manages obtainingprogramming120 as theprogramming120 is being multicast broadcast.Multicast module134 receives programming120 vianetwork106, and forwards the data obtained from the multicast broadcast toprogram playback module138 for playback, and/or tolocal storage module136 for storage.

Local storage module136 manages the storage of programming data on a local storage device ofconsumer device104.Module136 can implement, for example, a digital video recorder (DVR). In one or more embodiments this local storage device is included as part of consumer device104 (e.g., an internal disk drive of consumer device104). An example of such a local storage device is shown as storage device140(1). Alternatively, this local storage device can be coupled toconsumer device104, such as via a bus (e.g., an IEEE 1394 bus, a universal serial bus (USB), a wireless universal serial bus (wireless USB), etc.), via a local network (e.g., a LAN), and so forth. An example of such a local storage device is shown as storage device140(M). Programming that is obtained byunicast module132 and/ormulticast module134 can be stored in thelocal storage device140 bylocal storage module136.

Program playback module138 manages the playback of programming byconsumer device104.Consumer device104 can include display and/or audio playback components via which programming is played back, or alternativelyconsumer device104 can output a signal to one or more other components or devices which in turn can display and/or audibly playback the programming. The video content of programming can be played back on any type of television, monitor, LCD, projector, or similar television-based display system that renders video and/or image data. The audio content of programming can be played back on any type of television, stereo, or similar television-based audible playback system that renders audio data.

The programming played back byprogram playback module138 can be programming received fromunicast module132, programming received frommulticast module134, and/or programming retrieved from alocal storage device140 bylocal storage module136.Playback module136 can playback programs that have been received in their entirety, as well as portions of programs (e.g., one part of a program can be played back while one or more other parts of the program are being received frommulticast module134 or unicast module132).

Users can input requests toconsumer devices104 for programming to be played back and/or recorded in a variety of different manners. In one or more embodiments, an electronic programming guide (EPG) is displayed to the user. The EPG includes a listing of various programs that are available, and optionally other information such as a channel on which the programs are available, a time at which the programs are aired, summary information describing the programs, and so forth. The user can navigate through the EPG in any of a variety of conventional manners (e.g., using directional keys on a remote control device) to select a particular program that he or she desires to have recorded. Alternatively, such requests can be input in other manners, such as selection of a program from a drop-down menu, inputting text identifying the program, selecting of one or more channel identifiers on a remote control (e.g., entering a channel number on the remote control), and so forth. Additionally, requests can optionally be forwarded toconsumer device104 from another device. For example, a user of a handheld device or cellular phone can send a request toconsumer device104 to request playback and/or recording of particular programming.

During operation, a user ofconsumer device104 can requestparticular programming120. This request can be a request to view and/or record theprogramming120. Additionally, this request can be a request to view a particular program, or alternatively to just watch whatever programming is currently being aired on a particular channel. Situations often arise where the user requestsparticular programming120 after a particular program has already begun airing. In such situations,unicast module132 establishes a unicast session withserver unicast module112 ofserver102 in order to obtain the portion of the particular program that has already begun airing fromnetwork buffer114. Once the programming data obtained via the unicast session catches up to the programming data being multicast asprogramming120, the unicast session can be terminated and the remaining portion of the programming obtained via the multicast broadcast.

In situations where the user requests to view and/or record a particular program, then the previously aired portion of that program is obtained as the previously aired portion of the programming byunicast module132 via a unicast session. The previously aired portion of a program is the portion of the program that was aired starting with the beginning of the program and spanning up to the time of the user request. The previously aired portion of the program can be readily identified byconsumer device104 and/orserver102 using programming guide data (e.g., EPG data) or other metadata associated withprogramming120.

In situations where the user requests to view and/or record a particular channel rather than requesting a particular program, the previously aired portion of the programming can be identified in different manners. In one or more embodiments, a current program being aired on the channel is identified and the previously aired portion of the programming is the previously aired portion of the identified program. The program can be identified in different manners, such as via programming guide data or other metadata associated withprogramming120.

In other embodiments, the previously aired portion of the programming is identified by going backwards in time from the point in time at which the request was received. For example, the previously aired portion of the program can be a certain amount of time before the point in time at which the request was received (e.g., the preceding 15 minutes, the preceding hour, etc.). By way of another example, the previously aired portion of the programming can be the programming received since a most recent particular interval before the point in time at which the request was received (e.g., the most recent time on the hour, the most recent time on the half-hour, and so forth). As a specific example, if the request was received at 5:37 pm, then the previously aired programming could be the programming from 5:30 pm to 5:37 pm, from 5:00 pm to 5:37 pm, from 4:00 pm to 5:37 pm, and so forth. It is further to be appreciated that the previously aired portion of the programming can alternatively be identified in other manners.

In one or more embodiments, the user request is a request to playback and/or record particular programming after the airing of the programming has already begun. This request can be made by the user in a variety of different manners. The request could be a specific “restart” request via which the user requests playback and/or recording of the programming even though airing of the programming has already begun. The “restart” request invokes the restart TV functionality discussed herein. The “restart” request could be input by the user in a variety of different manners, such as by pressing a “restart” key, selecting an on-screen “restart” menu option, selecting a program that has already begun airing from an electronic programming guide, other inputs, and so forth. Alternatively, the request could be inferred by other user inputs, such as tuning to a particular channel. For example,consumer device104 can be configured so that whenever the user tunes to or otherwise requests programming from certain channels, the tuning or other request is interpreted as a request to playback programming that has already begun airing. These certain channels can be set in different manners, such as via user preferences, device default settings, and so forth.

By way of yet another example, the “restart” request can be inherently input when a user enters a “rewind” or “skip back” command (e.g., presses a “rewind” or “skip back” button on a remote control). In response to such a command, the programming will be played back rolling backwards, using first any portion already captured onlocal storage device140 and then continuing with a portion received via a unicast session withserver102. In one or more embodiments, the user can rewind up to the earliest point of time of programming available on server102 (e.g., 4 hours ago) or up to a point that is the beginning of the current program. When the user reaches that point the programming received via the unicast session withserver102 automatically starts playing (in the normal forward direction). If the user were to enter a “fast forward” or “skip” command, playback of the programming at a faster rate would continue with programming received via the unicast session withserver102 until the data received via the unicast session catches up to the multicast broadcast (or to data stored on local storage device140).

The user request could also be a request automatically input on behalf of the user, or inherent in some other request or situation. For example, a “restart” request can be incorporated into a recovery process in which a portion of the programming was missed due to a failure or other problem (e.g., a device or system crashes). As part of the recovery process, a “restart” request is included so that the missed portion of the programming can be obtained via a unicast session withserver102.

As indicated above, once the programming data obtained via the unicast session catches up to the programming data being multicast asprogramming120, the unicast session can be terminated and the remaining portion of the programming can be obtained from another source. The manner in which the unicast session catches up to the programming data being multicast asprogramming120 can vary. Generally, the data being received via the unicast session catching up to the multicast broadcast refers to the situation where the data from the unicast session is the same as the data being multicast broadcast.

In the discussions herein, reference is made to bandwidth and the amount of bandwidth available to theconsumer devices104. Generally, the amount of bandwidth available to aparticular consumer device104 refers to the amount of data that theparticular device104 can receive. Bandwidth is oftentimes expressed in megabits per second (Mbps), although other units of measure can alternatively be used. The amount of data that adevice104 can receive can vary based on the particular device, the location of the device, a type of network the device is coupled to, other data being transferred to the device, and so forth.

In one or more embodiments,consumer device104 obtains the previously aired portion of the programming via the unicast session concurrently with obtaining at least a portion of the remaining portion of the programming being multicast asprogramming120. In such embodiments, it is assumed thatconsumer device104 has sufficient bandwidth to obtain the portions of the program via the unicast session and the multicast broadcast concurrently. By way of example, assume that programming is played back atconsumer device104 at a rate of 1 Mbps, and thatconsumer device104 has 2 Mbps of available bandwidth. Accordingly, the previously aired programming is transferred toconsumer device104 via the unicast session at a rate of 1 Mbps, and the multicast broadcast of the remaining portion of the programming is broadcast at a rate of 1 Mbps. Accordingly, in thisexample consumer device104 would use the available 2 Mbps of bandwidth in order to concurrently obtain both the previously aired programming and the remaining programming. In this example, the unicast session catches up to the multicast broadcast at the time in the programming thatconsumer device104 began obtaining the remaining portion of the program via the multicast broadcast.

FIG.2 illustrates an example of the reducing unicast session duration with restart TV in accordance with one or more embodiments.FIG.2 illustrates an example situation where the previously aired portion of the programming is obtained via the unicast session concurrently with obtaining at least a portion of the remaining portion of the programming. In the example ofFIG.2,programming200 is represented by a bar. A request to playback and/orrecord programming200 after it has begun airing is received attime202. A previously aired portion of the programming spanning from aprogramming beginning time204 and thetime202 of the request is transferred to the consumer device via a unicast session. Thisbeginning time204 can be a time at which a particular program began airing, or alternatively this previously aired portion can be identified in other manners as discussed above.

The remaining portion of theprogramming200, spanning fromtime202 to theprogramming ending time206 is transferred to the consumer device via the multicast broadcast. Theprogramming ending time206 refers to the time at which the consumer device stops recording and/or playing back theprogramming200 being received. Thisprogramming ending time206 can be identified in different manners, such as being the time at which airing of a particular program requested by the user ends, being the time at which the user changes channels, and so forth.

The example ofFIG.2 assumes that the previously aired programming is obtained by the consumer device at the same rate as the programming is played back by the consumer device. Accordingly, for an amount oftime210 after thetime202 of the request, the previously aired portion of the programming is obtained via the unicast session concurrently with obtaining the remaining portion of the programming via the multicast broadcast. The amount oftime210 is approximately equivalent to the amount oftime212 between the beginningtime204 and thetime202 of the request.

As the multicast broadcast is obtained, it is stored on a local storage device by the consumer device (e.g., by alocal storage module136 ofFIG.1). In response to the request received attime202, playback ofprogramming200 at the consumer device begins at beginningtime204 using the programming data obtained via the unicast session. After amount oftime212 elapses, the playback ofprogramming200 at the consumer device continues using the data from the multicast broadcast that was stored on the local storage device. Accordingly, the unicast session can be terminated after the amount oftime212 elapses as the unicast session has caught up with the multicast broadcast. The remaining portion ofprogramming200 is played back from the multicast broadcast data stored on the local storage device by the consumer device. The duration of the unicast session can thus be reduced because the remaining portion ofprogramming200 is obtained via the multicast broadcast.

It should also be noted that, in the example ofFIG.2, after the unicast session is terminated the remaining portion ofprogramming200 is typically played back from the local storage device of the consumer device. As the user requested playback of theprogramming200 after theprogramming200 had already begun airing, the user is essentially watching a delayed version of programming200 (delayed relative to the time theprogramming200 is aired). Accordingly, after the unicast session is terminated, part ofprogramming200 previously recorded by the consumer device from the multicast broadcast is played back, while concurrently portions ofprogramming200 being multicast broadcast are recorded for subsequent playback.

Returning toFIG.1, situations can arise whereconsumer device104 has additional bandwidth beyond that used for the unicast session and the multicast broadcast. In such situations, the previously aired programming can be transferred toconsumer device104 via the unicast session at a rate that is faster than the rate at which the programming is played back. This transferring of the data at a faster rate allows the previously aired portion of the programming to catch up to the multicast broadcast more quickly, and allows the unicast session to thus be terminated more quickly.

By way of example, assume that programming is played back atconsumer device104 at a rate of 1 Mbps, and thatconsumer device104 has 3 Mbps of available bandwidth. The remaining portion of the programming is multicast broadcast at a rate of 1 Mbps. The previously aired portion of the programming is obtained via the unicast session at a rate up to the 2 Mbps available bandwidth, allowing the previously aired portion of the program to be obtained at twice the rate as it is played back. Accordingly, in thisexample consumer device104 would use the available 3 Mbps of bandwidth in order to concurrently obtain both the previously aired programming and the remaining programming. In this example, the unicast session catches up to the multicast broadcast at a time in the programming prior to the time at whichconsumer device104 began obtaining the remaining portion of the program via the multicast broadcast.

FIG.3 illustrates an example of the reducing unicast session duration with restart TV in accordance with one or more embodiments.FIG.3 illustrates an example situation where the previously aired portion of the programming is obtained via the unicast session concurrently with obtaining at least a portion of the remaining portion of the programming, and whereconsumer device104 has additional bandwidth beyond that used for the unicast session and the multicast broadcast. In the example ofFIG.3,programming200 is represented by a bar. A request to playback and/orrecord programming200 after it has begun airing is received attime202. A previously aired portion ofprogramming200 spanning from aprogramming beginning time204 and thetime202 of the request is transferred to the consumer device via a unicast session. The remaining portion ofprogramming200, spanning fromtime202 to theprogramming ending time206 is transferred to the consumer device via the multicast broadcast. Thesetimes202,204, and206 are those discussed above with reference toFIG.2.

InFIG.3, at least part of the remaining portion of the programming is obtained by the consumer device concurrently with the unicast session. The example ofFIG.3 assumes that the previously aired programming is obtained by the consumer device at a rate that is faster than the rate at which the programming is played back by the consumer device. Accordingly, for an amount oftime302 after thetime202 of the request, the previously aired portion of theprogramming200 is obtained via the unicast session concurrently with obtaining the remaining portion of theprogramming200 via the multicast broadcast. The amount oftime302 is less than the amount oftime304 between the beginningtime204 and thetime202 of the request because of the faster transfer rate.

As the multicast broadcast is obtained, it is stored on a local storage device by the consumer device (e.g., by alocal storage module136 ofFIG.1). Additionally, the excess bandwidth is used by the unicast session to transfer portions ofprogramming200 beginning attime202 working backwards towards beginningtime204. These portions transferred in the excess bandwidth are also stored on the local storage device by the consumer device (e.g., by alocal storage module136 ofFIG.1).

In response to the request received attime202, playback ofprogramming200 at the consumer device begins at beginningtime204 using the programming data obtained via the unicast session. After the part ofprogramming200 that was originally aired betweentime204 andtime202 has been transferred via the unicast session (the amount of time302), playback ofprogramming200 at the consumer device continues using the data stored on the local storage device of the consumer device. This playback from the local storage device begins using the data that was stored from the unicast session (the data transferred in the excess bandwidth), then continues using the data from the multicast broadcast. Accordingly, the unicast session can be terminated after the amount oftime302 elapses as the unicast session has caught up with the multicast broadcast. The duration of the unicast session can thus be reduced because the remaining portion ofprogramming200 is obtained via the multicast broadcast, and further because the excess bandwidth is used to obtain the previously aired portion ofprogramming200 more quickly.

Alternatively, the unicast session can be used to obtain the previously aired portion of the programming in other manners other than using the excess bandwidth to transfer portions ofprogramming200 beginning attime202 working backwards towards beginningtime204. By way of example, the unicast session could use the excess bandwidth to generate a buffer locally on the consumer device (e.g., bylocal storage module136 ofFIG.1). This buffer would be filled working forward fromtime204 totime202, until the unicast session catches up to the multicast broadcast. In this example, the previously aired programming is played back from the buffer on the consumer device rather than being played back as it is received in the unicast session.

Returning toFIG.1, situations can arise whereconsumer device104 does not have sufficient bandwidth to obtain both the previously aired programming via the unicast session and the remaining portion of the programming via the multicast broadcast concurrently. In such situations,consumer device104 obtains the data for the programming via the unicast session until the data obtained via the unicast session catches up with the multicast broadcast. If there is sufficient bandwidth, the data can be transferred toconsumer device104 via the unicast session at a rate that is faster than the rate at which the programming is played back in order to catch up with the multicast broadcast quicker.

By way of example, assume that programming is played back atconsumer device104 at a rate of 1 Mbps, that the programming is multicast broadcast at a rate of 1 Mbps, and thatconsumer device104 has 1.5 Mbps of available bandwidth. The previously aired portion of the programming is obtained via the unicast session at a rate up to the 1.5 Mbps available bandwidth. Additional portions of the programming aired after the request to playback and/or record the programming are also obtained via the unicast session. In this example, the unicast session catches up to the multicast broadcast at a time in the programming after the time at which the user requested playback and/or recording of the programming.

FIG.4 illustrates an example of the reducing unicast session duration with restart TV in accordance with one or more embodiments.FIG.4 illustrates an example situation where the consumer device has insufficient bandwidth to obtain both the previously aired programming via the unicast session and the remaining portion of the programming via the multicast broadcast concurrently. In the example ofFIG.4,programming200 is represented by a bar, theprogramming200 having abeginning time204 and anending time206. A request to playback and/or record programming after it has begun airing is received attime202. Thesetimes202,204, and206 are those discussed above with reference toFIG.2.

In response to the request to playback and/orrecord programming200 attime202, transfer of a previously aired portion of the programming fromprogramming beginning time204 begins. The portion ofprogramming200 being multicast broadcast is not received and stored by the consumer device as there is insufficient bandwidth for the consumer device to do so.

If there is no excess bandwidth beyond the rate at which the consumer device plays back programming200, then the unicast session typically does not catch up to the multicast session. However, if there is excess bandwidth beyond the rate at which the consumer device plays back programming200, then the unicast session can catch up to the multicast broadcast, typically at some time aftertime202. Whether the unicast session catches up to the multicast broadcast, and if so the exact time at which the unicast session catches up to the multicast broadcast, can vary based on the amount of excess bandwidth, thetime202 the request was received, and how much time remains between thetime202 the request was received and theprogramming ending time206.

FIG.4 illustrates one example where the consumer device has excess bandwidth beyond the rate at which the consumer device plays backprogramming200. In this example, the unicast session catches up to the multicast broadcast at atime402 that is later inprogramming200 than thetime202 that the request was received. The consumer device stores on a local storage device (e.g., using alocal storage module136 ofFIG.1) portions ofprogramming200 obtained via the unicast session that are not yet played back. Once the unicast session catches up to the multicast broadcast, the consumer device begins storing the multicast data on the local storage device (e.g., using alocal storage module136 ofFIG.1). In this example,portion404 of the programming is obtained via the unicast session, whileportion406 of the programming is obtained via the multicast broadcast. The duration of the unicast session can thus be reduced because of the excess bandwidth being used to obtain portions ofprogramming200 more quickly.

Thus, following this example inFIG.4, in response to the request attime202, playback of the programming begins with the programming being obtained via the unicast session. After the unicast session catches up to the multicast broadcast, playback of the programming continues using the data stored on the local storage device of the consumer device. This playback from the local storage device begins using the data that was stored from the unicast session (the data transferred in the excess bandwidth), then continues using the data from the multicast broadcast.

In alternate embodiments, situations where the consumer device has insufficient bandwidth to obtain programming from the unicast session and the multicast broadcast concurrently are managed differently. By way of example, if the multicast broadcast protocol allows the multicast broadcast to be joined even if the consumer device has insufficient bandwidth, then the consumer device can obtain part of the programming via the multicast broadcast concurrently with obtaining part of the programming via the unicast session. Any parts of the multicast broadcast that could not be recorded due to the insufficient bandwidth can be obtained in other manners, such as via the unicast session, via another multicast broadcast, and so forth.

Various examples are discussed with reference toFIGS.2-4 above. These examples refer to the playback ofprogramming200, although it is to be appreciated that the techniques discussed above can be used in situations whereprogramming200 is being recorded but not yet played back. In such situations, the data received via the unicast session is recorded to the local storage device of the consumer device rather than being played back. Subsequently, in response to a user request to playback the data, the programming data received via the unicast session and the multicast session is played back from the local storage device.

Also in the discussions ofFIGS.2-4, reference is made to atime202 that a request is being received. It is to be appreciated that various actions based ontime202 are only approximations, and that various delays may be present with respect totime202. For example, a delay (e.g., 300 milliseconds, 2 seconds, 5 seconds, etc.) may exist between the time the user physically inputs a request and the time the consumer device begins obtaining and recording the multicast broadcast.

As discussed above, a switch from obtaining data via the unicast session to obtaining data from another source is made when the unicast session catches up to the multicast broadcast. Generally, this catching up refers to the situation where the data received (or to be received) via the unicast session is the same as the data received (or to be received) via the multicast broadcast. This situation can be identified in a variety of different manners.

In one or more embodiments, the programming is separated into multiple pieces or packets each having an associated timestamp. This timestamp can be, for example, the time at which that piece or packet is to be played back relative to the other pieces or packets in the programming (e.g., a presentation timestamp), the time at which the piece or packet is to be sent to consumer devices relative to the other pieces or packets in the programming (e.g., a delivery timestamp), a specific date and/or time at which that piece or packet is to be played back, and so forth. When the timestamp for a piece or packet received via the unicast session is the same as the timestamp for a piece or packet being broadcast via the multicast broadcast, then the unicast session has caught up to the multicast broadcast. In one or more embodiments, this determination of when the timestamps are the same can be made by a server (e.g.,server102 ofFIG.1). Alternatively, the timestamps for pieces or packets being broadcast via the multicast broadcast can be made available to the consumer device, in which case the consumer device can make the determination.

FIG.5 is a flowchart illustrating anexample process500 for reducing unicast session duration with restart TV in accordance with one or more embodiments.Process500 is carried out by a consumer device, such as adevice104 ofFIG.1, and can be implemented in software, firmware, hardware, or combinations thereof.Process500 is an example process for reducing unicast session duration with restart TV. Additional discussions of reducing unicast session duration with restart TV are included herein with reference to different figures.

Inprocess500, a unicast session is established with a server (act502). This unicast session is typically established in response to a request from a user of the consumer device to playback and/or record programming that has already begun airing. A first portion of programming is obtained via the unicast session (act504). A check is made as to whether the data in the unicast session has caught up with the multicast broadcast of the programming (act506), and this first portion continues to be obtained via the unicast session until the data in the unicast session catches up with the multicast broadcast of the programming. As discussed above, the point at which the unicast session catches up with the multicast broadcast of the programming can vary, based at least in part on the time when the request to playback and/or record the programming is received and the amount of bandwidth available to the consumer device. Also as discussed above, the unicast session can be determined to have caught up to the multicast session in a variety of different manners.

When the data obtained in the unicast session has caught up with the multicast broadcast of the programming, then the consumer device switches to obtaining the remaining portion of the programming from a different source (act508). As discussed above, this different source could be a local storage device (e.g., a local DVR), or could be the multicast broadcast. As part of this switching, a request to terminate the unicast session can be sent to the server.

FIG.6 is a flowchart illustrating anexample process600 for reducing unicast session duration with restart TV in accordance with one or more embodiments.Process600 is carried out by a server, such as aserver102 ofFIG.1, and can be implemented in software, firmware, hardware, or combinations thereof.Process600 is an example process for reducing unicast session duration with restart TV. Additional discussions of reducing unicast session duration with restart TV are included herein with reference to different figures.

Inprocess600, a unicast session is established with a consumer device (act602). This unicast session is typically established in response to a request from a user of the consumer device to playback and/or record programming that has already begun airing. A first portion of programming is sent to the consumer device via the unicast session (act604). This first portion continues to be sent via the unicast session until the data in the unicast session catches up with the multicast broadcast of the programming (act606). As discussed above, the point at which the unicast session catches up with the multicast broadcast of the programming can vary, based at least in part on the time when the request to playback and/or record the programming is received and the amount of bandwidth available to the consumer device. Also as discussed above, the unicast session can be determined to have caught up to the multicast session in a variety of different manners.

When the data obtained in the unicast session has caught up with the multicast broadcast of the programming, then the unicast session is terminated (act608). In one or more embodiments the server determines when the unicast session has caught up with the multicast broadcast of the program, and terminates the unicast session at that time. The server also optionally informs the consumer device that the unicast session is being terminated, and that the consumer device is to obtain the remaining portion of the programming from another source. In other embodiments, the consumer device determines when the unicast session has caught up with the multicast broadcast of the program, and informs the server that the unicast session is to be terminated.

It should be noted that, in one or more embodiments various changes can be made to the particular programming that is obtained by the consumer device via the unicast session and/or the multicast broadcast. For example, if the user were to fast forward through part of the previously aired programming being obtained via the unicast session, then that part that is fast forwarded through would not need to be obtained via the unicast session, allowing the unicast session to catch up to the multicast broadcast sooner.

FIG.7 illustrates various components of anexample client device700 that can be implemented as any form of a computing, electronic, or television client device to implement one or more embodiments of the reducing unicast session duration with restart TV. For example,client device700 can be implemented as any of the consumer devices104(1-M) shown inFIG.1. In various embodiments,client device700 can be implemented as any one or combination of a television client device, a gaming system, or as any other computing-based device, such as a desktop computer, a portable computer, a television set-top box, a digital video recorder (DVR), an appliance device, a gaming console, and/or as any other type of computing-based client device.

Client device700 includes one or moremedia content inputs702 that may include Internet Protocol (IP) inputs over which streams of media content (programming) are received via an IP-based network. These streams can be received via unicast sessions and/or multicast broadcasts as discussed above.Client device700 further includes communication interface(s)704 that can be implemented as any one or more of a serial and/or parallel interface, a wireless interface, any type of network interface, a modem, and as any other type of communication interface. A wireless interface enablesclient device700 to receive control input commands706 and other information from an input device, such as fromremote control device708, a portable computing-based device (such as a cellular phone)710, or from another infrared (IR), 802.11, Bluetooth, or similar RF input device.

A network interface provides a connection betweenclient device700 and a communication network by which other electronic and computing devices can communicate data withdevice700. Similarly, a serial and/or parallel interface provides for data communication directly betweenclient device700 and the other electronic or computing devices. A modem facilitatesclient device700 communication with other electronic and computing devices via a conventional telephone line, a DSL connection, cable, and/or other type of connection.

Client device700 also includes one or more processors712 (e.g., any of microprocessors, controllers, and the like) which process various computer-executable instructions to control the operation ofdevice700, to communicate with other electronic and computing devices, and to implement embodiments of the local recording of previously aired programming.Client device700 can be implemented with computer-readable media714, such as one or more memory components, examples of which include random access memory (RAM), non-volatile memory (e.g., any one or more of a read-only memory (ROM), flash memory, EPROM, EEPROM, etc.), and a disk storage device. A disk storage device can include any type of magnetic or optical storage device, such as a hard disk drive, a recordable and/or rewriteable compact disc (CD), a DVD, a DVD+RW, and the like.

Computer-readable media714 provides data storage mechanisms to store various information and/or data such as software applications and any other types of information and data related to operational aspects ofclient device700. For example, anoperating system716 and/orother computer applications718 can be maintained as software applications with the computer-readable media714 and executed on processor(s)712 to implement embodiments of the local recording of previously aired programming.

Client device700 can also include a program guide application720 that is implemented to process program guide data and generate program guides for display. A program guide enables a viewer to navigate through an onscreen display and locate various media content such as broadcast programs, recorded programs, video-on-demand programs and movies, interactive game selections, network-based applications, and other media content of interest to the viewer.

Client device700 can also include aDVR system724 withplayback application726, andrecording media728 to maintain recordedmedia content730 thatclient device700 downloads (or otherwise receives) and/or records.DVR system724 can optionally includelocal storage module136 ofFIG.1. Further,client device700 may access or receive additional recorded media content that is maintained with a remote data store (not shown).Client device700 may also receive media content from a video-on-demand server, or media content that is maintained at a broadcast center or content distributor that distributes the media content to subscriber sites and client devices. Theplayback application726 is a video control application that can be implemented to control the playback of media content, the recordedmedia content730, and/or other video-on-demand media content, music, and any other audio, video, and/or image media content which can be rendered and/or displayed for viewing.

Client device700 also includes an audio and/orvideo output732 that provides audio and/or video data to an audio rendering and/ordisplay system734. The audio rendering and/ordisplay system734 can include any devices that process, display, and/or otherwise render audio, video, and image data. Video signals and audio signals can be communicated fromclient device700 to adisplay device736 via an RF (radio frequency) link, S-video link, composite video link, component video link, DVI (digital video interface), analog audio connection, or other similar communication link. Alternatively, the audio rendering and/ordisplay system734 can be implemented as integrated components of theexample client device700.Client device700 along with the audio rendering and/ordisplay system734 is an example of a viewing system that can be implemented in a household viewing area for viewing television programs and/or receiving other television media content.

FIG.8 illustrates an example entertainment andinformation system800 in which one or more embodiments of the reducing unicast session duration with restart TV can be implemented.System800 facilitates the distribution of media content, program guide data, and advertising content to multiple viewers and to multiple viewing systems.System800 includes acontent distributor802 and any number “N” of client systems804(1-N) each configured for communication via acommunication network806. Each client system804(1-N) is an example of the consumer devices104(1-M) described with reference toFIG.1. Each of the client systems804(1-N) can receive data streams of media content, program content, program guide data, advertising content, closed captions data, and the like from content server(s) of thecontent distributor802 via thecommunication network806.

Thecommunication network806 can be implemented as any one or combination of a wide area network (e.g., the Internet), a local area network (LAN), an intranet, an IP-based network, a broadcast network, a wireless network, a Digital Subscriber Line (DSL) network infrastructure, a point-to-point coupling infrastructure, or as any other media content distribution network. Additionally,communication network806 can be implemented using any type of network topology and any network communication protocol, and can be represented or otherwise implemented as a combination of two or more networks. A digital network can include various hardwired and/or wireless links808(1-N), routers, gateways, and so on to facilitate communication betweencontent distributor802 and the client systems804(1-N).

System800 includes amedia server810 that receives media content from acontent source812, program guide data from aprogram guide source814, and advertising content from anadvertisement source816. In one or more embodiments, themedia server810 represents an acquisition server that receives the audio and video media content fromcontent source812, an EPG server that receives the program guide data fromprogram guide source814, and/or an advertising management server that receives the advertising content from theadvertisement source816.

Thecontent source812, theprogram guide source814, and theadvertisement source816 control distribution of the media content, the program guide data, and the advertising content to themedia server810 and/or to other servers. The media content, program guide data, and advertising content can be distributed viavarious transmission media818, such as satellite transmission, radio frequency transmission, cable transmission, and/or via any number of other wired or wireless transmission media. In this example,media server810 is shown as an independent component ofsystem800 that communicates the program content, program guide data, and advertising content tocontent distributor802. In an alternate implementation,media server810 can be implemented as a component ofcontent distributor802.

Content distributor802 is representative of a headend service in a content distribution system, for example, that provides the media content, program guide data, and advertising content to multiple subscribers (e.g., the client systems804(1-N)). Thecontent distributor802 can be implemented as a satellite operator, a network television operator, a cable operator, and the like to control distribution of media content, program and advertising content, such as movies, television programs, commercials, music, and other audio, video, and/or image content to the client systems804(1-N).

Content distributor802 includes variouscontent distribution components820 to facilitate media content processing and distribution, such as a subscriber manager, a device monitor, and one or more content servers. The subscriber manager manages subscriber data, and the device monitor monitors the client systems804(1-N) (e.g., and the subscribers), and maintains monitored client state information.

Although the various managers, servers, and monitors of content distributor802 (to include themedia server810 in one or more embodiments) are described as distributed, independent components ofcontent distributor802, any one or more of the managers, servers, and monitors can be implemented together as a multi-functional component ofcontent distributor802. Additionally, any one or more of the managers, servers, and monitors described with reference tosystem800 can implement features and embodiments of the reducing unicast session duration with restart TV.

Thecontent distributor802 includes communication interface(s)822 that can be implemented as any type of interface to communicate and receive data from client devices of the television system, including unicast sessions and/or multicast broadcasts as discussed above. Thecontent distributor802 also includes one or more processors824 (e.g., any of microprocessors, controllers, and the like) which process various computer-executable instructions to control the operation ofcontent distributor802. Thecontent distributor802 also includes anetwork buffer838 that operates analogous to network buffer114 ofFIG.1, temporarily storing programs received from content source812 (e.g., via media server810). Thecontent distributor802 can be implemented with computer-readable media826 which provides data storage to maintain software applications such as anoperating system828 andmedia content830 for distribution to the client systems804(1-N).

The client systems804(1-N) can each be implemented to include aclient device832 and a display device834 (e.g., a television, LCD, and the like). Aclient device832 of arespective client system804 can be implemented in any number of embodiments, such as a set-top box, a digital video recorder (DVR) and playback system, an appliance device, a gaming system, and as any other type of client device that may be implemented in an entertainment and information system. In an alternate embodiment, client system804(N) is implemented with acomputing device836 as well as a client device. Thecomputing device836 is an example of a connected data store that can record and maintain media content for a client device. Additionally, anyclient device832 of arespective client system804 can implement features and embodiments of the reducing unicast session duration with restart TV as described herein.

Generally, any of the functions or techniques described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations. The terms “module” and “component” as used herein generally represent software, firmware, hardware, or combinations thereof. In the case of a software implementation, the module or component represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer-readable memory devices, further description of which may be found with reference toFIGS.7 and8. The features of the local recording of previously aired programming techniques described herein are platform-independent, meaning that the techniques can be implemented on a variety of commercial computing platforms having a variety of processors.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims (40)

What is claimed is:

1. A method implemented in a consumer device, the method comprising:

receiving a request at a first time for programming that has already begun to air transmit, wherein the programming is scheduled for transmission to a plurality of users user devices during a scheduled time interval, and wherein the first time corresponds to a point after a beginning time of the scheduled time interval;

determining the beginning time of the scheduled time interval;

obtaining by the consumer device, based on determining the beginning time, via a unicast session with a server, a first portion of the programming aired transmitted prior to the first time, the first portion including previously aired transmitted programming, wherein the previously aired transmitted programming corresponds to programming transmitted to a the plurality of users user devices starting from the beginning time of the scheduled time interval, and wherein the first portion is obtained as a first plurality of packets, each packet of the first plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the first plurality of packets;

obtaining by the consumer device, via a multicast broadcast of the programming concurrently with obtaining the first portion by the consumer device via the unicast session, at least part of a remaining portion of the programming that airs transmitted after the first time, wherein initiating said obtaining the first portion of the programming and said obtaining the remaining portion of the programming begin together at the consumer device, and wherein the multicast broadcast is obtained as a second plurality of packets, each packet of the second plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the second plurality of packets;

comparing a first presentation timestamp of a first packet of the first plurality of packets with a second presentation timestamp of a second packet of the second plurality of packets;

determining, based on the comparing, whether the a first presentation timestamp of the a first packet of the first plurality of packets matches the a second presentation timestamp of the a second packet of the second plurality of packets;

in response to determining that the first presentation timestamp of the first packet of the first plurality of packets matches the second presentation timestamp of the second packet of the second plurality of packets, determining that the unicast session has caught up to the multicast broadcast; and

stopping, the unicast session when the unicast session has caught up to the multicast broadcast, to obtain the programming data from the unicast session, and continuing to obtain via the multicast broadcast the remaining portion of the programming from a different source other than the server.

2. A method as recited inclaim 1, further comprising:

storing at least the part of the remaining portion on a storage device of the consumer device; and

wherein the stopping comprises terminating the unicast session.

3. A method as recited inclaim 2, wherein the obtaining the first portion of programming comprises obtaining the first portion of the programming at a rate faster than a playback rate of the programming.

4. A method as recited inclaim 1, wherein the stopping comprises terminating the unicast session.

5. A method as recited inclaim 4, further comprising obtaining, via the unicast session with the server, an additional portion of programming aired transmitted after the request for the programming is received but before the unicast session catches up to the multicast broadcast of the programming.

6. A method as recited inclaim 1, wherein the programming is scheduled for transmission during a plurality of scheduled time intervals, wherein the scheduled time interval is a first of the plurality of scheduled time intervals, further comprising:

selecting a second of the plurality of scheduled time intervals that precedes the first scheduled time interval;

identifying a beginning time of the second scheduled time interval; and

wherein the obtaining comprises obtaining, via the unicast session, programming transmitted to a the plurality of users user devices starting from the beginning time of the second scheduled time interval.

7. A method as recited inclaim 1, wherein:

the request for the programming is a user request to playback particular programming; and

the obtaining and the stopping are performed in response to the user request.

8. A method as recited inclaim 1, wherein the stopping comprises sending a termination request to the server to terminate the unicast session.

9. A method as recited inclaim 1, further comprising playing back the first portion as the first portion is received via the unicast session, and playing back the remaining portion from the different source.

10. A method implemented in a computing device, the method comprising:

sending, to a consumer device via a unicast session with the consumer device, a first portion of programming aired transmitted prior to a first time that corresponds to a request to at least one of view or record the programming, the first portion including previously aired transmitted programming and being identifiable using metadata associated with the programming that indicates the previously aired transmitted programming spans from a beginning of the programming up to the first time that corresponds to the request to at least one of view or record the programming, wherein the programming is scheduled for transmission to a plurality of users user devices during a scheduled time interval, and wherein the first time corresponds to a point after a beginning time of the scheduled time interval, wherein the consumer device is initiated to obtain the first portion of the programming via the unicast session concurrently with obtaining a multicast broadcast of the programming via the multicast broadcast of the programming, wherein initiating said obtaining the first portion of the programming and said obtaining the multicast broadcast of the programming begin together at the consumer device, wherein the first portion is obtained as a first plurality of packets, each packet of the first plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the first plurality of packets, and the multicast broadcast is obtained as a second plurality of packets, each packet of the second plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the second plurality of packets, wherein the first portion corresponds to programming transmitted to a the plurality of users user devices starting from the beginning time of the scheduled time interval, and wherein the multicast broadcast of the programming is configured for storage to enable playback by the consumer device after the first portion of the programming is played back by the consumer device;

comparing a first presentation timestamp of a first packet of the first plurality of packets with a second presentation timestamp of a second packet of the second plurality of packets;

determining, based on the comparing, whether the a first presentation timestamp of the a first packet of the first plurality of packets matches the a second presentation timestamp of the a second packet of the second plurality of packets;

in response to determining that the first presentation timestamp of the first packet of the first plurality of packets matches the second presentation timestamp of the second packet of the second plurality of packets, determining that the unicast session has caught up to the stored multicast broadcast of the programming; and

stopping the unicast session when the unicast session has caught up to the stored multicast broadcast of the programming.

11. A method as recited inclaim 10, wherein the terminating comprises terminating the unicast session in response to a termination request received from the consumer device to terminate the unicast session.

12. A method as recited inclaim 10, wherein the sending comprising using excess bandwidth of the consumer device to send the first portion at a rate faster than a playback rate of the programming.

13. A method as recited inclaim 10, further comprising sending, via the unicast session with the consumer device, an additional portion of programming aired transmitted after the first time but before the unicast session catches up to the multicast broadcast of the programming.

14. A method as recited inclaim 10, wherein the request to view the programming comprises a request to restart a program at the consumer device, and wherein sending the first portion comprises sending the first portion in response to the request to restart the program.

15. A system for communication with a consumer device having a local storage device, the system comprising:

a server configured to establish a unicast session and/or a multicast broadcast with the consumer device, the server comprising:

memory circuitry configured to store content of the unicast session and/or the multicast broadcast for distribution to the consumer device; and

controlprocessing circuitry configured to:

receive a request from the consumer device at a first time for programming that has already begun to air transmit , wherein the programming is scheduled for transmission to a plurality of users user devices during a scheduled time interval, and wherein the first time corresponds to a point after a beginning time of the scheduled time interval;

establish a the unicast session with a at the server based on the received request;

determine the beginning time of the scheduled time interval;

obtain, based on determining the beginning time, via the unicast session and in response to the request, a first portion of the programming that aired transmitted prior to a first time, the first portion including previously aired transmitted programming and being identifiable using metadata associated with the programming that indicates the previously aired transmitted programming spans from a beginning of the programming up to the first time, wherein the first portion is obtained at a rate faster than a playback rate of the programming, and wherein the first portion is obtained for playback by the consumer device, wherein the first portion corresponds to programming transmitted to a the plurality of users user devices starting from the beginning time of the scheduled time interval, and wherein the first portion is obtained as a first plurality of packets, each packet of the plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the first plurality of packets;

obtain the first portion of the programming via the unicast session, together with obtaining and recording, via a the multicast broadcast of the programming, at least a first part of the multicast broadcast of the programming, at the consumer device, wherein the multicast broadcast is obtained as a second plurality of packets, each packet of the second plurality of packets having a presentation timestamp that indicates a play time of media data that is associated with a corresponding packet of the second plurality of packets;

compare a first presentation timestamp of a first packet of the first plurality of packets with a second presentation timestamp of a second packet of the second plurality of packets;

determine, based on the comparing, whether the a first presentation timestamp of the a first packet of the first plurality of packets matches the a second presentation timestamp of the a second packet of the second plurality of packets;

in response to determining that the first presentation timestamp of the first packet of the first plurality of packets matches the second presentation timestamp of the second packet of the second plurality of packets, determining that data obtained via the unicast session has caught up to the recorded multicast broadcast; and

stop, based on determining that data obtained via the unicast session has caught up to the recorded multicast broadcast, obtaining via the unicast session, the first portion of the programming, and obtaining a remaining portion of the programming from a the local storage device of the consumer device on which the at least the first part of the multicast broadcast was recorded, wherein the remaining portion is obtained for playback by the consumer device.

16. The system defined byclaim 15, wherein the control processing circuitry is configured to record a second part of the multicast broadcast on the local storage device while the first part of the multicast broadcast is being played back from the local storage device.

17. The system defined byclaim 15, wherein the request for the programming corresponds to a user request, received by the consumer device, to restart a television program.

18. The method defined byclaim 1, further comprising storing the first portion of the programming and the at least part of the remaining portion of the programming concurrently to memory.

19. The method defined byclaim 10, wherein the first portion of the programming and the at least part of the remaining portion of the programming are stored concurrently to memory.

20. The system defined byclaim 15, wherein the control processing circuitry is further configured to store the first portion of the programming and the at least part of the remaining portion of the programming concurrently to memory.

21. A method for playing, on a media device, a portion of programming that was broadcast prior to a time at which the media device began playing the programming the method comprising:

beginning to obtain, at a first time, via a first stream, programming that is scheduled for broadcast during a scheduled time interval, wherein the first time corresponds to a point after a beginning time of the scheduled time interval;

receiving, at a second time later than the first time, a request for a portion of the programming that was broadcast prior to the first time;

in response to receiving the request:

obtaining, via a second stream, a first plurality of packets containing media data of a first portion of the programming that was broadcast prior to the first time, each packet of the first plurality of packets having a presentation timestamp that indicates a respective play time of media data;

continuing to obtain, via the first stream, the programming, wherein the first stream is obtained as a second plurality of packets, each packet of the second plurality of packets having respective a presentation timestamp that indicates a play time of media data;

in response to determining that a presentation timestamp of the most recently obtained packet of the second plurality of packets matches a presentation timestamp of a most recently obtained packet of the first plurality of packets, determining, when playing the programming, that the second stream has caught up to the first stream; and

in response to determining that the second stream has caught up to the first stream, ending obtaining the second stream, and continuing to obtain via the first stream a remaining portion of the programming;

wherein the first stream is a multicast broadcast and the second stream is a unicast session.

22. The method ofclaim 21, further comprising storing at least the part of the remaining portion on a storage device of the media device.

23. The method ofclaim 21, wherein obtaining the first portion of programming comprises obtaining the first portion of the programming at a rate faster than a playback rate of the programming.

24. The method ofclaim 21, wherein at least part of the first portion of programming is stored on a storage device of the media device.

25. The method ofclaim 21, further comprising:

obtaining, via the unicast session, an additional portion of programming that is broadcast after the request is received but before the unicast session catches up to the multicast broadcast of the programming.

26. The method ofclaim 21, wherein the programming is scheduled for transmission during a plurality of scheduled time intervals, wherein the scheduled time interval is a first of the plurality of scheduled time intervals, further comprising:

selecting a second of the plurality of scheduled time intervals that precedes the first scheduled time interval;

identifying a beginning time of the second scheduled time interval; and

wherein the obtaining comprises obtaining, via the second stream, programming transmitted to a plurality of user devices starting from the beginning time of the second scheduled time interval.

27. The method ofclaim 21, wherein:

the request for the programming is a user request to play particular programming; and

the obtaining, via the second stream, and the ending of the second stream are performed in response to the user request.

28. The method ofclaim 21, wherein the ending comprises sending a termination request to a server to terminate the second stream.

29. The method ofclaim 21, further comprising playing the first portion as the first portion is received via the second stream and playing the remaining portion from the different source.

30. The method ofclaim 21, further comprising generating for display a notification to at least one of the plurality of user devices that the second stream is ending.

31. A system for playing a portion of programming that was broadcast prior to a time at which the media device began playing the programming, the system comprising:

a server configured to establish a second stream and/or a first stream with the media device, the server comprising:

memory circuitry configured to store content of the second stream and/or the first stream for distribution to the media device; and

processing circuitry configured to:

begin to obtain, at a first time, via the first stream, programming that is scheduled for broadcast during a scheduled time interval, wherein the first time corresponds to a point after a beginning time of the scheduled time interval;

receive, at a second time later than the first time, a request from the media device for a portion of the programming that was broadcast prior to the first time;

in response to receiving the request:

obtain, via the second stream, a first plurality of packets containing media data of a first portion of the programming that was broadcast prior to the first time, each packet of the first plurality of packets having a presentation timestamp that indicates a respective play time of media data;

continue to obtain, via the first stream, the programming, wherein the first stream is obtained as a second plurality of packets, each packet of the second plurality of packets having respective a presentation timestamp that indicates a play time of media data;

in response to determining that a presentation timestamp of the most recently obtained packet of the second plurality of packets matches a presentation timestamp of a most recently obtained packet of the first plurality of packets, determine, when playing the programming, that the second stream has caught up to the first stream; and

in response to determining that the second stream has caught up to the first stream, end obtaining the second stream, and continue to obtain via the first stream a remaining portion of the programming;

wherein the first stream is a multicast broadcast and the second stream is a unicast session.

32. The system ofclaim 31, further comprising a storage device, wherein the processing circuitry is further configured to store at least the part of the remaining portion on the storage device.

33. The system ofclaim 31, wherein the processing circuitry configured to obtain the first portion of programming is further configured to obtain the first portion of the programming at a rate faster than a playback rate of the programming.

34. The system ofclaim 31, further comprising a storage device, wherein at least part of the first portion of programming is stored on the storage device.

35. The system ofclaim 31, wherein the processing circuitry is further configured to obtain, via the second stream, an additional portion of programming that is broadcast after the request is received but before the second stream catches up to the first stream of the programming.

36. The system ofclaim 31, wherein the programming is scheduled for transmission during a plurality of scheduled time intervals, wherein the scheduled time interval is a first of the plurality of scheduled time intervals, and wherein the processing circuitry is further configured to:

select a second of the plurality of scheduled time intervals that precedes the first scheduled time interval;

identify a beginning time of the second scheduled time interval; and

wherein the obtaining comprises obtaining, via the second stream, programming transmitted to a plurality of user devices starting from the beginning time of the second scheduled time interval.

37. The system ofclaim 31, wherein:

the request for the programming is a user request to play particular programming; and

the processing circuitry is further configured to perform the obtaining, via the second stream, and the ending of the second stream in response to the user request.

38. The system ofclaim 31, wherein the processing circuitry configured to end the second stream is further configured to send a termination request to a server to terminate the second stream.

39. The system ofclaim 31, wherein the processing circuitry is further configured to play the first portion as the first portion is received via the second stream and playing the remaining portion from the different source.

40. The system ofclaim 31, wherein the processing circuitry is further configured to generate for display a notification to at least one of the plurality of user devices that the second stream is ending.

Images