Intelligent Media Queue
Systems, methods, and non-transitory computer-readable storage media for intelligently managing a playlist of digital media provide an intelligent dynamic queue that is configured to manage the playback of digital media. The queue can transition between passive playback mode, active playback mode, and mixed playback mode. The queue can handle the playback of the songs in the queue according to the playback mode and/or a queue status field that is associated with each song in the queue.
This application is a Continuation of U.S. application Ser. No. 17/339,789, filed on Jun. 4, 2021, entitled “Intelligent Media Queue,” which is a Continuation of U.S. application Ser. No. 16/141,574, filed on Sep. 25, 2018, entitled “Intelligent Media Queue,” which is a Continuation of U.S. application Ser. No. 15/182,902, filed on Jun. 15, 2016, entitled “Intelligent Media Queue,” which is a Continuation of U.S. application Ser. No. 13/609,169, filed on Sep. 10, 2012, entitled “Intelligent Media Queue,” each of which are expressly incorporated by reference herein in their entireties.
BACKGROUND 1. Technical FieldThe present disclosure relates generally to playing digital media content and, more specifically, to techniques and systems for creating a dynamic playlist for managing the playback of digital media content.
2. IntroductionIn recent years, electronic devices capable of playing digital music have become commonplace. For instance, electronic devices such as laptop computers, handheld digital media players, smart phones, and handheld gaming systems are used daily by society to listen to music. As a result of the growing popularity of these electronic devices, the sale of digital music has grown dramatically. Users can utilize various avenues to access digital music, including visiting an online store to purchase digital music as a single track or a complete album. Users can also share their music with one another or stream music online.
As the amount of digital media available to a user increases, improved techniques must be applied to organize and manage this information. Traditionally, playlists have been used to organize the music into collections, and, through a selection of a song or through a selection of a playlist from such collections, the music can be played. The playlists would be stored persistently and be selectable by the consumer when he or she wishes to play the songs associated with the playlist. However, these traditional techniques are very limiting in that they require the overhead of creating a playlist and storing it. Moreover, the traditional playlist environment is not well suited for dynamic changes to a consumer's desires. For example, assume that a student is playing music from a playlist in his dorm room. His friend comes into his room and wants to listen to a song that is not in the currently playing playlist. Traditionally, selecting the one song to play would terminate playback of the playlist or the song would be added into the persistent playlist, thus becoming a part of the playlist. Both of these behaviors are undesirable to the student, who would like to continue listening to his playlist after his friend listens to the song, and would not desire to have the friend's selection added to his playlist.
While there have been many advancements in the use and distribution of digital media, there is still a need for improved techniques for managing playback of digital media.
SUMMARYAdditional features and advantages of the disclosure will be set forth in the description which follows, and will become apparent from the description, or can be learned by practice of the herein disclosed principles by those skilled in the art. The features and advantages of the disclosure can be realized and obtained by means of the disclosed instrumentalities and combinations as set forth in detail herein. These and other features of the disclosure will become more fully apparent from the following description, or can be learned by the practice of the principles set forth herein.
Disclosed are systems, methods, and non-transitory computer-readable storage media for intelligently managing the playback of digital media. The digital media can include audio songs, videos, movies, images, photos, and other digital media content. An intelligent dynamic queue is configured to manage the playback of digital media. A user can submit requests to playback digital media (from a single source or various sources) by adding the digital media to the queue. Depending on the digital media added and the process used to add the digital media, the digital media can take on different properties. The media playback application can manage the handling of the digital media in the queue by utilizing a queue status field that is associated with each digital media item in the queue. In some examples, the queue can contain multiple entries that specify the playback sequence. Each entry can be associated with a digital media item and can also include a queue status field. The queue status field stores a variable describing whether the digital media item associated with the entry is manually queued (i.e., the digital media item was explicitly added to the queue) or automatically queued (i.e., the digital media item was implicitly added to the queue via a predetermined collection, such as a playlist).
In one embodiment, some entries in the queue can be purged (e.g., deleted) when a triggering event occurs. Exemplary triggering events include changing the media source or adding a collection of digital media to the queue. For example, the media playback application can be configured to purge the queue when the media source changes, when an album is added to the queue, when a playlist is added to the queue, and/or other scenarios. The determination of which entries to purge can depend on the queue status field of each entry. In one example, entries in the queue that have a queue status field set to manual entry remain in the queue because the user explicitly requested the digital media item. In contrast, entries that have a queue status field set to automatic entry are deleted from the queue because they were automatically added into the queue. In some embodiments, the queue status field of a digital media item in the queue can be updated as other digital media items enter the queue.
In order to describe the manner in which the above-recited and other advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:
Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure.
The present disclosure addresses the need in the art for systems, techniques, and methods for improved playback management of digital media. The digital media can include digital songs, movies, videos, podcasts, music videos, images, photos, and other digital media content. While the disclosure focuses on playback management for digital songs, it is to be understood by a person of ordinary skill in the relevant art that these teachings also apply to playback management for other forms of digital media such as movies, images, videos, photos, podcasts, etc.
The present disclosure focuses on an intelligent queue that is used by a media playback application to manage the playback of digital media items. An intelligent queue is different than a traditional playlist. An intelligent queue can contain media items from multiple media sources, some of the sources being remotely located. If one of the remote sources were to go offline, the integrity of the queue is not affected since the intelligent queue is configured to skip songs that are offline. In contrast, a traditional playlist generally contains only items that are locally stored on a playback device. Playlists can sometimes play back media from multiple sources however, when one of the sources go offline, the playlist's integrity is lost. Moreover, an intelligent queue can be dynamically modified by adding other media items into the queue in real time whereas modifications to a playlist are persistent in that they are stored in memory. Furthermore, the intelligent queue is capable of interpreting the user's intentions based on where the user adds digital media into the queue and as a result, affect how other media items in the intelligent queue are handled.
In some examples, different types of digital media can co-exist in a single queue. For example, a queue can include a song and a video that are presented in a specified playback order. A user can submit requests to a media playback application to add songs (or other types of digital media) from a single source or from various sources to the queue. Each song can be linked or otherwise associated with an entry in the queue. Besides adding an individual digital media item, entire playlists, albums, and other collections of music can be selected for addition to the queue. When the collection of music is added, the digital media within the collection are added to the queue. Playback of music by the media playback application can be based on the queue and more specifically, the order that the songs appear in the queue. Since the user can in real time add digital media to the queue, the queue is dynamic and changes constantly based on the user's desires. In some embodiments, the queue is also persistent in that un-played tracks that are in the queue when the media playback application closes will remain queued for playback the next time the media playback application opens.
Through the intelligent queue, the media playback application is capable of seamlessly changing in between two different modes of operation. In a first mode, the media playback application operates in a normal playback mode. In the normal playback mode, the media playback application begins by playing the first song in the playlist and continues to sequentially play through the tracks in the playlist until the last song is played. In a temporary playback mode, songs can be dynamically entered and played back in a specified order. When the list is done, playback is completed and the list is cleared. Traditionally these different modes of operation have been mutually exclusive however through the use of the intelligent queue, the media playback application is able to seamlessly switch between the two modes according to actions items and triggering events initiated by the user. For example, dragging a song into the queue can result in the media playback application transitioning from a normal playback mode to the temporary playback mode. Once the song has completed, the media playback application can transition back to the normal playback mode. Therefore, the media playback application is capable of operating in a normal playback mode that does not require user interaction and then subsequently change to a temporary playback mode when a request is received to listen to a song. Listening to the song does not abandon the normal playback mode. Instead, the media playback application returns to the normal playback mode when the song has completed.
The media playback application can associate queue status fields to a song when the song is added to the queue. More specifically, each entry in the queue can store information related to a song. For example, the information can include a link to the song and a queue status field of the song. Depending on the queue status field associated with the song, the song can be handled differently by the media playback application. In one embodiment, each entry can include a queue status field configured to identify whether a song was manually entered or automatically entered. Manually entered songs can remain in the queue when the source of music changes. As another example, songs that were automatically entered into the queue can be purged from the queue when the source of music changes. The media playback application interprets manually entered songs as songs that the user has explicitly selected to listen to, either now or in the future. In contrast, songs that are automatically entered (e.g., queuing songs from an internet radio station such as Pandora® or queuing songs from a playlist) generally belong to a collection of songs that share a commonality, the commonality being that the songs all belong to a collection that was selected by the user to be added to the queue. Since this commonality is the reason that the songs were added to the queue (and not because the user has manually selected each song to be added into the queue), these songs are volatile and in some instances can be deleted from the queue when the source changes or when the media playback application closes. Examples of songs that are automatically entered into the queue include the situation where a user selects a playlist to be added to the queue or where the user requests the media playback application for ten songs that are similar to a selected seed song. The recommended songs are added to the queue. In some examples, the media playback application can include rules for editing the behavior of the media playback application, such as setting the circumstances when the type (manually entered or automatically entered) should be changed in an entry. Additional details about automatically entered and manually entered songs are discussed below.
Media Playback ApplicationIn one embodiment, content bar 110 can be organized into sources 120 and playlists 130. Sources 120 display a list of sources of music that are available to the user. Here, the sources include local music library 122 (e.g., music library that the user has stored locally on his device), home share 124 (e.g., music from the music libraries of other users on the same network), streaming 126 (e.g., music that the user streams from remote sources, such as internet radio stations), and cloud storage 128 (e.g., music stored remotely that the user has rights to play or is otherwise associated with the user). Available music that is not stored on the user's local device can be accessed through Wifi, Bluetooth, Intranet, Internet, and other connection options. In other embodiments, other types of media can exist in the sources, such as movies and TV shows. However for simplicity, only audio tracks are discussed. A person of ordinary skill in the art would be able to expand the teachings here to other types of media, such as movies, images, podcasts, videos, photos, etc.
Playlists 130 shows a list of playlists that are available to the user. The playlists can be generated by the user or automatically generated by a third-party service, a remote server, or the media playback application. Here, playlists 130 include DJ playlist 132, playlist A 134 and playlist B 136. Playlist A 134 and playlist B 136 may include a collection of songs that are available to the user from sources 120. DJ playlist 132 can include a collection of songs that was automatically generated by the media playback application or a remote server. In one embodiment, the media playback application automatically creates the collection of music based on parameters provided by the user. For example, top rated songs can be added and prioritized by placing them in a higher queue position than other songs. In some examples, DJ playlist 132 can be dynamically generated whenever the playlist is selected. This can allow DJ playlist 132 to take advantage of up to date metadata when automatically selecting the songs to play. In other examples, DJ playlist 132 can be generated or regenerated based on user request.
Queue 150 displays an ordered list of songs for playback. The songs in the list can be from multiple sources or multiple playlists. The order that the songs appear in queue 150 is the playback sequence of the queue. When a currently playing song is finished or about to be finished playing on a media player device, the next song in the queue is retrieved for playback. For media stored remotely (i.e., not stored on the user's device), the media playback application can pre-fetch a predetermined number of songs in the queue from the remote source and store them locally for future playback. This may improve performance by reducing the opportunity for the music to refresh or lag during playback. The retrieved song is removed from the ordered list and the remaining songs in the list are promoted up one cell. Since songs can be dynamically selected and added into the queue, queue 150 also is dynamic in nature. Thus, a user can add songs into the queue. In other examples, other people using other devices can add songs to the queue. Queue 150 can also be persistent, thus allowing songs that were scheduled for playback to be presented to the user the next time the user starts the media playback application.
Here, queue 150 includes entries 152, 154, and 156, each identifying a song from a particular media source. The three songs 152, 154, and 156 are located under heading 153 titled “Up Next.” The songs are presented in a specified playback order. Thus, the next song to be played is the song identified by entry 152, followed by the song identified by entry 154, followed by the song identified by entry 156. In some examples, heading 153 can also present other information associated with the origin of this grouping of songs. For example if the songs are all part of a playlist, the name of the playlist can also be presented in heading 153. This can be useful to provide additional information about the collection of music that the user is currently listening to. In some examples, each entry 152, 154, 156 can display additional information about the song in an auxiliary view that is displayed when a cursor is placed over the song. For example, queue 150 may by default be configured to display the title of the song and the duration of the song. However when the cursor is placed over the entry, song metadata such as lyrics, artist, genre, rating, etc. can also be displayed in an auxiliary view. In other examples, hidden action items that can be performed on the entry can also be presented when the cursor is placed over the song or the cursor rolls over the song/entry. For example, action items such as skip song, promote song to play next, promote song to play immediately, rate song, create a playlist by using the song as a root song, and others can be presented to the user when the cursor is placed over the song/entry. In other examples, one or more of these action items can be fixed on the entry and presented along with the default information displayed. Here, entry 156 presents shortcut 157 along with the title and duration (i.e., default information). Shortcut 157 can be linked to a predefined or user defined action item associated with the song such as skip song or move song to play next. In some examples, shortcut 157 can appear on a rollover.
Queue 150 can also include a history icon 151. History icon 151, when selected, presents a list of songs that have been previously played by the media playback application. The list of previously played songs can include songs from different sources and playlists. In one embodiment, a predefined minimum play time can be applied to songs that are partially played to determine whether the song should be added into the history. For example, a user who is sampling songs from his music library (i.e., quickly listening to a few seconds of a song for purposes of evaluating a song or selecting songs to be added to a playlist or other container) may not want the sampled songs to be included into the history since doing so may clutter the history. As another example, a user who listens to the first few seconds of a song may decide to skip it and not wish for the song to be displayed in the history. This can be prevented by setting minimum play time parameters that are to be met before a song is added into history. For instance, a minimum play time parameter may state that a song must be played for 10 seconds before it is added into the history. In some examples, the list of upcoming songs shown in queue 150 can be replaced with the list of items that have been previously played when history 151 is selected. In other examples, the information presented for each song in history can vary depending on the source or playlist. For example, radio sources can present the name of the radio station and optionally the name of the song. As another example, a playlist can be associated with a color scheme, icon, or other identifier. In the history, songs from that playlist can be presented with the identifier. Media playback application can also include window 160 configured to display the currently playing song. As songs finish and the next song is fetched from the queue, the song presented in window 160 can change. In some examples, queue 150 can be configured to also display the currently playing song in a entry above banner 153.
Queue 150 can be presented as a window of a given size. The size of the window can be fixed or dynamic. In one embodiment, the size of the window can dynamically change based on the size of the GUI of the media playback application or other windows of the media playback application. For example, as the media playback application is resized by the user, queue 150 can also be resized. The number of entries presented in queue 150 can also vary depending on the size of queue 150. If there are more items in the queue (or history) that can be presented in the number of entries available, different UI techniques such as a “show more” option to see additional pages of items or scroll functionality can be implemented to view or access those additional items.
Intelligent Media QueueAs shown in
In some examples, the media playback application can use heuristics to determine whether the playlist is being added for the specific tracks within the playlist or for the dominant theme of the playlist. Dominant themes can be songs that are highly ranked, songs having the same genre, songs that have the same artist, or songs that have any other common theme, When the playlist is selected for its theme rather than the individual tracks in the playlist, the tracks in the playlist can be purged from the queue when the user wishes to listen to something else (e.g., another playlist, album, or other collection of music.) For example, purging can remove tracks that were automatically entered into the queue. For instance, adding a smart type playlist to the queue results in a plurality of non-user selected being added into the queue. If the user wishes to listen to a single song, a detour can be created in the queue where the song is played followed by continued playback of the playlist. If the user does not switch to something else, the songs in the queue can be played in sequential order.
While a playlist is described here, the heuristics can also be applied to other collections of music, such as albums and smart playlists (e.g., playlists that have been automatically generated based on one or more seed songs). In some examples, user settings can be set to define how the media playback application handles different collections. For example, user settings can define that songs within a particular type of collection should be treated as an automatic entry or a manual entry. As another example, the user settings can define that a type of collection having more than a predefined number of media items should have all items within the collection be treated as automatic entries. A song can have a queue status field that can be set to manual entry or automatic entry. Manual entry is a song that the media playback application interprets as a song that the user has made a conscious decision to manually enter into the queue. A manual entry can be treated differently than an automatic entry (e.g., a song that gets automatically added into the queue based on a user's selection of a collection of music). For example, the user settings or rules can define the media playback application's behavior when a playlist, album, or other collection of music is added to the queue. Default settings can also be set when the user has not defined the user settings. When media is added to the queue, the media can be animated as it enters the queue, thus creating the appearance that the media is being physically added to the queue.
The media player may pre-fetch a predetermined number of songs from the radio station or other remote source. The predetermined number can be set to a small value to minimize wasted costs from fetched songs that are not played back. The predetermined number can also be set to a large enough value to prevent poor playback performance due to periods of slow downloading speeds or periods of inability to communicate with the remote source. In some examples, the predetermined number can be dynamically updated based on the performance of the remote source and the client device running the media playback application. For example, the media player application can increase the predetermined number when poor playback performance is experienced due to poor wireless service. This can occur when the client device is located in a metropolitan city with many users or in the mountainside where reception is sparse. By increasing the predetermined number of media items that are buffered, the media playback application is capable of not communicating with the remote source for a longer period of time and therefore lowering the likelihood that the buffer will be depleted before the client device is able to communicate with the remote source. As another example, the predetermined number can be decreased when the media playback application determines that the number of songs that are fetched but not played back is greater than a given threshold. In some examples, the predetermined number can be temporarily increased (or decreased) and subsequently returned to its original value.
In some examples where the collection being added to queue 200 contains more media items than the number of entries in queue 200, the media playback application can automatically populate entries in the queue with songs from the collection when the entries become available. For example, queue 200 can be populated with songs 211-213 of playlist 210 when playlist 210 is added into queue 200. When song 211 transitions to being currently played, songs 212 and 213 are promoted up an entry, thus leaving the last entry empty. As a result, song 214 is added to queue 200 to fill the available entry. In other examples, additional pages or a scrolling functionality can be implemented to view songs 214 and 215.
In some examples, the music player application may analyze a request to add a collection of songs before the collection of songs is added into the queue. Various rules can be applied during the analysis. For example, the media playback application may analyze the number of songs in a playlist before adding the songs to the queue. If the number of songs is greater than a predefined limit, a prompt can be presented to the user to confirm whether the user intended to add the songs to the queue. As another example, the type of the container can be used in the analysis. For instance, a prompt can be presented when adding a playlist but not presented when adding an individual song or album.
Banner 340 of queue 300 provides a synopsis of the upcoming tracks in the queue. Here, banner 340 is configured to display the number of manually entered songs in the queue that are coming up. In contrast when the upcoming songs are automatically entered songs (or when the media playback application is in a passive playback mode), banner 340 is configured to display the title of the collection that the songs belong to (e.g., playlist title, album title, radio station title, etc.). Thus, the information presented on the banner of queue can vary depending on the songs in the queue and/or the playback mode.
Queue ActionsIn some examples, skipping a song can alter the queue status field of other entries in the queue. For example, the media playback application can interpret the action of skipping a song in the queue as meaning that the user wishes to listen to the songs not skipped. If the user did not want to listen to the other songs in the queue, the user could have skipped those songs also. As a result, songs that remain in the queue after a skip command can be converted to being manually entered. In one example, only entries in the queue above the skipped song are converted to being manually entered since it is possible that the user is glancing over the list from the top down. As such, only the queue status fields of songs above the currently skipped song are candidate to be altered. Entries that have a queue status field of manually entered can be preserved in the queue when the queue is purged.
In one embodiment, the media playback application can include a rule configured to treat all songs that appear before the newly added song as songs that should be played in the queue. The user has deliberately added the song after these songs and thus, it can be presumed that the user would like to hear all the songs placed before the location of the added song. Thus, the media playback application can convert an attribute of songs in front of the added song that were originally set as an automatic entry into a manual entry.
Here, queue 500 can be similar or substantially similar to queue 400 of
When a song is manually added to a queue while the media playback application is in a passive playback mode (i.e., the entries in the queue are automatic entries), the media playback application can enter a mixed playback mode. When the media playback application is in a mixed playback mode, songs that are scheduled to play before the currently added song can have their queue status field set to manual entry, if necessary, to signify that the user has made a conscious decision to play all the songs queued above the currently added song. This ensures that song 540 and all songs in the queue above song 540 (e.g., song 510) are played by the media playback application in the specified order. In other words, songs that are set to manual entry are not purged. After adding in song 540, queue 500 now includes both manual entries and automatic entries. In some embodiments, a queue having multiple types of entries can include separate banners for each type of entry. For example, manual entries can be grouped together and associated with one banner while automatic entries can be grouped together and associated with another banner. Here, banner 503 is configured to describe the manual entries. As shown, banner 503 describes that there are two queued songs to be played next. Similarly, banner 505 is configured to notify the user that after these two manually queued songs, the media playback application will return to the playing music from the playlist. Here, the name of the playlist can be displayed. If the playlist has additional songs not present in the queue, they can be added into the queue as entries in the queue become available. In some examples, all actions to add songs into the queue are treated as manual entries once the user has manually entered songs into the queue. This is because treating entries as automatic entries may destructively clear the manual entries from the queue.
In some embodiments, the shuffle command may take on different functionality based on the type of entries in the queue. For example, if the queue contains both manual entries and automatic entries, a shuffle command performed may only shuffle the automatic entries in the queue. This is because the manual entries were placed in a specific order by the user and thus, should be played back in that order. As another example, the performance of the shuffle command can be based on both the type of entries in the queue and the currently playing song. For example, if the currently playing song is a manual entry, all the manual entries in the queue can be shuffled. Similarly if the currently playing song is an automatic entry, all the automatic entries in the queue can be shuffled. User defined options can be configured to override this default behavior.
While the example illustrated in
Besides adding songs into the queue, actions can also be performed to existing songs in the queue. In some embodiments, different actions can be performed on songs in the queue to change the order or properties/attributes of the songs in the queue. Exemplary actions include drag and drop, play next, and play immediately. For example, drag and drop can move the song from the drag location to the drop location. As another example, play next can move the song from its current location to the first entry in the queue. As yet another example, play immediately can be a combination of two actions. The first action is similar to a play next command where the song is promoted to the first entry in the queue. The second action can be skipping the currently playing song. Therefore, the queue and the attributes of the songs within the queue can change depending on the action performed.
In one embodiment, the media playback application can include intelligence that is used when processing a request to place a song (either an existing song in the queue or adding a song from a source) as the next song in the queue. When a user adds a song to a queue, a determination is made as to whether the user intended the song to be added as the next song to be played or if the user intended the song to be added at the end of a logical collection of songs, one of which is currently being played. A logical collection of songs in some instances can be considered a single work. Since the collection of songs is considered a single work, they are treated as belonging to a single container that the user intends to listen to in sequence. Examples of a container of songs include albums and smart playlists (playlists automatically generated, sometimes based on a theme or trait) containing songs that have similar traits (artist, genre, year, ranking, etc.) based on a selected seed song. For example, if the currently playing song is part of an album, the intention of selecting an action item to place a song as the next song in the queue may be for the song to play following the playing of the album. In some examples, a playlist can also be considered a container. In some examples, heuristics can be used to determine when a collection of music is considered a container of music. These heuristics can be based on user settings that have been set to differentiate a container of music form a collection of music. Exemplary user settings can include a limit to the number of songs that can exist in a container, the similarity of metadata between the songs in the container, and other factors. In some examples, the media playback application can apply container rules to determine when a collection of music is a container. These rules can be weighted in making the determination. Exemplary rules can include a weighting factor if the artist is the same in the collection of music, another weighting factor if the album name is the same in the collection of music, another weighting factor if the genre is the same in the collection of music, another weighting factor if the ratings provided to the songs are similar within a predetermined range, and others.
Here, the media playback application may, as a result of the heuristics, determine that the currently playing song and songs 610, 620, and 630 belong to the same container and thus are required to be played together before other songs can be played. Since the container has already begun playing the currently playing song, the remainder of the container (song 610, 620, and 630) are played before any other song is played. As a result, the ordered list of songs in queue 600 is song 610, song 620, song 630, and song 640. The media playback application may determine that song 640 is a manual entry because it was manually selected and entered into the queue by the user. As such, queue status field 645 is set to “M” for manual entry. In one example, the media playback application can subsequently determine that there are three songs in front of manually entered song 640. Based on a rule stored on the media playback application, songs in front of a manually entered song can be converted into manual entries. As a result, queue status fields 615, 625, 635, are converted to manual entries.
As shown in
In some embodiments, the media playback application can periodically purge (i.e., delete) songs from the queue. Purging entries in the queue can be a housekeeping technique performed by the media playback application to maintain the quality of the queue. In some examples, a song can be purged from the queue based on the how the song entered the queue. For example if the song was a manual entry, it is confident that the user desires to listen to the song. As a result, manual entries are not purged. In contrast if the song was an automatic entry, it is uncertain whether the user desires to listen to this specific song or to the collection that the song belongs to. As a result, automatic entries are purged. Automatically entered entries can have a lower priority over manually entered entries since it is unclear whether the songs were added into the queue because the user selected a collection that contains the song or the user intended to play the song. Songs with higher priority can be played before songs with lower priority. In one example, the automatically entered entries can be considered volatile entries and can be replaced when a triggering event occurs, such as switching the playlist or the source.
In one embodiment, rules can be generated by the media playback application to control the purging behavior of the queue. For example, a rule can be created to purge the queue of automatic entries whenever the source changes. The media playback application can interpret the user's command to change sources as an implicit notification that the user no longer wishes to listen to music from the previous source. As a result, automatic entries which the user did not explicitly add are removed from the queue. In another example, a rule can be created where the queue is purged of automatic entries whenever a collection of media is added to the queue. The collection of media, which can be a playlist or album, can include a plurality of songs. The media playback application can interpret the addition of this collection of media to the queue as meaning that the user is done listening to a previously selected collection of music. As a result, the media playback application can purge the automatic entries from the queue.
In some embodiments, the queue can also be configured to present a history list containing songs that have been previously played by the media playback application. The history list can be configured to present a list of songs previously played from newest to oldest. A user can review the previously played songs and decide to purchase or re-queue certain songs for playback. Songs that were skipped or purged during playback are not added into the history list. In some examples, a predefined limit of time can be used by the media playback application to determine whether a song should be added to the history list. For example, a song that is played for less than 10 seconds is not added to the history list. Songs may be played for less than 10 seconds because the user was sampling music and song was skipped during playback or the song is no longer available. A song can be no longer available if the source of the song is no longer online. In some examples, the media playback application may try to find other sources that contain the song, such as the user's media library. If the song cannot be found in the available sources, then the song is skipped from the queue.
In one embodiment, the source of the song can affect the way the song is presented in the history list. For example, radio stations can be presented differently in the history list and the queue than other sources. A radio station can appear in the queue without specifics on the song that will be played. When the radio station is moved to the currently playing song, the name of the song is presented to the user. After the song has played, the song enters the history list. In the history list, the name of the song appears along with an option to purchase the song. The option to re-queue the song may not be provided to the user until the user owns a copy of the song.
Queue Sharing for Multiple DevicesIn one embodiment, a queue on a host device can be accessed by multiple client devices. Each client device can view the queue and optionally, edit the queue by adding songs, playlists, or other collections of music into the queue. In one example, a voting option is presented where the multiple client devices can vote on songs. Songs that meet certain voting criteria (such as minimum number of votes, minimum number of likes, or minimum average voting score) can be promoted in the queue to play next. In one example, songs promoted in the queue have a queue status field set as manually entered while other songs entered by the multiple client devices have a queue status field set as automatically entered. This allows only songs that are desirable by the community to be promoted up the queue. In another example, statistics from the voting can be used to analyze the songs in the queue. The statistics can be used to provide additional options to the users, such as “play highest ranked songs more often.”
MethodsA general computing device can be configured to store and execute the media playback application. With reference to
The system bus 1510 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input/output (BIOS) stored in ROM 1540 or the like, may provide the basic routine that helps to transfer information between elements within the computing device 1500, such as during start-up. The computing device 1500 further includes storage devices 1560 such as a hard disk drive, a magnetic disk drive, an optical disk drive, a solid state drive, a tape drive or the like. The storage device 1560 can include software modules 1562, 1564, 1566 for controlling the processor 1520. Other hardware or software modules are contemplated. The storage device 1560 is connected to the system bus 1510 by a drive interface. The drives and the associated computer readable storage media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the computing device 1500. In one aspect, a hardware module that performs a particular function includes the software component stored in a non-transitory computer-readable medium in connection with the necessary hardware components, such as the processor 1520, bus 1510, display 1570, and so forth, to carry out the function. The basic components are known to those of skill in the art and appropriate variations are contemplated depending on the type of device, such as whether the device 1500 is a small, handheld computing device, a desktop computer, or a computer server.
Although the exemplary embodiment described herein employs the hard disk 1560, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, digital versatile disks, cartridges, random access memories (RAMS) 1550, read only memory (ROM) 1540, a cable or wireless signal containing a bit stream and the like, may also be used in the exemplary operating environment. Non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.
To enable user interaction with the computing device 1500, an input device 1590 represents any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device 1570 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems enable a user to provide multiple types of input to communicate with the computing device 1500. The communications interface 1580 generally governs and manages the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.
For clarity of explanation, the illustrative system embodiment is presented as including individual functional blocks, including functional blocks labeled as a “processor” or processor 1520. The functions these blocks represent may be provided through the use of either shared or dedicated hardware, including, but not limited to, hardware capable of executing software and hardware, such as a processor 1520, that is purpose-built to operate as an equivalent to software executing on a general purpose processor. For example, the functions of one or more processors, presented in
The logical operations of the various embodiments are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a general use computer, (2) a sequence of computer implemented steps, operations, or procedures running on a specific-use programmable circuit; and/or (3) interconnected machine modules or program engines within the programmable circuits. The system 1500, shown in
Cloud computing is a type of Internet-based computing in which a variety of resources are hosted and/or controlled by an entity and made available by the entity to authorized users via the Internet. An exemplary cloud computing system configuration 1600 is illustrated in
System 1600 can be configured to include cloud computing resources 1620 (i.e., “the cloud”). The cloud resources can include a variety of hardware and/or software resources, such as cloud servers 1622, cloud databases 1624, cloud storage 1626, cloud networks 1628, cloud applications, cloud platforms, and/or any other cloud-based resources. In some cases, the cloud resources are distributed. For example, cloud storage 1626 can include multiple storage devices. In some cases, cloud resources can be distributed across multiple cloud computing systems and/or individual network enabled computing devices. For example, cloud computing resources 1620 can communicate with servers 16041, 16042, . . . , 1604n (collectively “1604”), database 1606, and/or any other network enabled computing device to provide the cloud resources.
Furthermore, in some cases, the cloud resources can be redundant. For example, if cloud computing resources 1620 is configured to provide data backup services, multiple copies of the data can be stored such that the data is still be available to the user even if a storage resource is offline, busy, or otherwise unavailable to process a request. In another example, if cloud computing resources 1620 is configured to provide software, the software can be available from different cloud servers so that the software can be served from any of the different cloud servers. Algorithms can be applied such that the closest server or from the server with the lowest current load is selected to process a given request.
In system 1600, a user interacts with cloud computing resources 1620 through user terminals 16021, 16022, . . . , 1602n (collectively “1602”) connected to a network by direct and/or indirect communication. Cloud computing resources 1620 can support connections from a variety of different electronic devices, such as servers; desktop computers; mobile computers; handheld communications devices, e.g., mobile phones, smart phones, tablets; set top boxes; network-enabled hard drives; and/or any other network-enabled computing devices. Furthermore, cloud computing resources 1620 can concurrently accept connections from and interact with multiple electronic devices. Interaction with the multiple electronic devices can be prioritized or occur simultaneously.
Cloud computing resources 1620 can provide cloud resources through a variety of deployment models, such as public, private, community, hybrid, and/or any other cloud deployment model. In some cases, cloud computing resources 1620 can support multiple deployment models. For example, cloud computing resources 1620 can provide one set of resources through a public deployment model and another set of resources through a private deployment model.
In some configurations, a user terminal 1602 can access cloud computing resources 1620 from any location where an Internet connection is available. However, in other cases, cloud computing resources 1620 can be configured to restrict access to certain resources such that a resource can only be accessed from certain locations. For example, if cloud computing resources 1620 is configured to provide a resource using a private deployment model, then cloud computing resources 1620 can restrict access to the resource, such as by requiring that a user terminal 1602 access the resource from behind a firewall.
Cloud computing resources 1620 can provide cloud resources to user terminals 1602 through a variety of service models, such as Software as a Service (SaaS), Platforms as a service (PaaS), Infrastructure as a Service (IaaS), and/or any other cloud service models. In some cases, cloud computing resources 1620 can provide multiple service models to a user terminal 1602. For example, cloud computing resources 1620 can provide both SaaS and IaaS to a user terminal 1602. In some cases, cloud computing resources 1620 can provide different service models to different user terminals 1602. For example, cloud computing resources 1620 can provide SaaS to user terminal 16021 and PaaS to user terminal 16022.
In some cases, cloud computing resources 1620 can maintain an account database. The account database can store profile information for registered users. The profile information can include resource access rights, such as software the user is permitted to use, maximum storage space, etc. The profile information can also include usage information, such as computing resources consumed, data storage location, security settings, personal configuration settings, etc. In some cases, the account database can reside on a database or server remote to cloud computing resources 1620 such as servers 1604 or database 1606.
Cloud computing resources 1620 can provide a variety of functionality that requires user interaction. Accordingly, a user interface (UI) can be provided for communicating with cloud computing resources 1620 and/or performing tasks associated with the cloud resources. The UI can be accessed via an end user terminal 1602 in communication with cloud computing resources 1620. The UI can be configured to operate in a variety of client modes, including a fat client mode, a thin client mode, or a hybrid client mode, depending on the storage and processing capabilities of cloud computing resources 1620 and/or the user terminal 1602. Therefore, a UI can be implemented as a standalone application operating at the user terminal in some embodiments. In other embodiments, a web browser-based portal can be used to provide the UI. Any other configuration to access cloud computing resources 1620 can also be used in the various embodiments.
As described above, in some configurations, the cloud computing resources can be used to store user data. The present disclosure contemplates that, in some instances, this gathered data might include personal and/or sensitive data. The present disclosure further contemplates that the entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such data should implement and consistently use privacy policies and practices that are, generally recognized, meeting or exceeding industry or governmental requirements for maintaining personal information data private and secure. For example, personal data from users should be collected for legitimate and reasonable uses of the entity and not shared or sold outside of those legitimate uses. Further, such collection should occur only after the informed consent of the users. Additionally, such entities should take any needed steps for safeguarding and securing access to such personal data and ensuring that others with access to the personal data adhere to their privacy and security policies and procedures. Further, such entities can subject themselves to evaluation by third parties to certify their adherence to widely accepted privacy policies and practices.
Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal data. For example, the present technology can be configured to allow users to select the data that is stored in cloud storage. In another example, the present technology can also be configured to allow a user to specify the data stored in cloud storage that can be shared with other users.
Therefore, although the present disclosure broadly covers use of personal data to implement one or more various disclosed embodiments, the present disclosure also contemplates that the various embodiments can also be implemented without the need for accessing such personal data. That is, the various embodiments of the present technology are not rendered inoperable due to the lack of all or a portion of such personal data. For example, non-personal data can be stored in cloud storage.
Embodiments within the scope of the present disclosure may also include tangible and/or non-transitory computer-readable storage media for carrying or having computer-executable instructions or data structures stored thereon. Such non-transitory computer-readable storage media can be any available media that can be accessed by a general purpose or special purpose computer, including the functional design of any special purpose processor as discussed above. By way of example, and not limitation, such non-transitory computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, solid state drives, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions, data structures, or processor chip design. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or combination thereof) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of the computer-readable media.
Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, components, data structures, objects, and the functions inherent in the design of special-purpose processors, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.
Those of skill in the art will appreciate that other embodiments of the disclosure may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
The various embodiments described above are provided by way of illustration only and should not be construed to limit the scope of the disclosure. For example, the principles herein can be applied other types of files to control the secure deletion of those files and other copies of those files from storage. Those skilled in the art will readily recognize various modifications and changes that may be made to the principles described herein without following the example embodiments and applications illustrated and described herein, and without departing from the spirit and scope of the disclosure.
Claims
1. (canceled)
2. A non-transitory computer readable medium comprising computer readable code executable by one or more processors to:
- cause to display a graphical user interface (GUI) depicting a toggle button and at least one of a queue representing a playback sequence of one or more media items and a history list separate from the queue representing one or more recently played media items;
- in response to receiving a selection of the toggle button, toggle display between the queue and the history list; and
- in response to receiving a selection of at least one media item in the history list, add the at least one media item to the queue.
3. The non-transitory computer readable medium of claim 2, further comprising computer readable code to:
- in response to a determination that a recently played media item meets a first criterion, add the recently played media item to the history list.
4. The non-transitory computer readable medium of claim 3, wherein the first criterion comprises a minimum play time parameter of the recently played media item.
5. The non-transitory computer readable medium of claim 3, wherein the first criterion comprises full playback of the recently played media item.
5. The non-transitory computer readable medium of claim 2, wherein the one or more recently played media items are listed sequentially in the history list based on playback order.
6. The non-transitory computer readable medium of claim 2, wherein the toggle button is displayed within a header window of the GUI, wherein the toggle button remains hidden from view until a user pointing device is within the header window of the GUI.
7. The non-transitory computer readable medium of claim 2, wherein the toggle button is displayed within a header window of the GUI, wherein the toggle button remains within a fixed position in the header window of the GUI.
8. The non-transitory computer readable medium of claim 2, wherein the one or more recently played media items in the history list are each displayed concurrently with one or more action buttons, wherein the one or more action buttons include purchase, play now, play next, add to queue, or a combination thereof.
9. A method, comprising:
- causing display of a graphical user interface (GUI) depicting a toggle button and at least one of a queue representing a playback sequence of one or more media items and a history list separate from the queue representing one or more recently played media items;
- in response to receiving a selection of the toggle button, toggle display between the queue and the history list; and
- in response to receiving a selection of at least one media item in the history list, adding the at least one media item to the queue.
10. The method of claim 9, further comprising:
- in response to a determination that a recently played media item meets a first criterion, adding the recently played media item to the history list.
11. The method of claim 10, wherein the first criterion comprises a minimum play time parameter of the recently played media item.
12. The method of claim 10, wherein the first criterion comprises full playback of the recently played media item.
13. The method of claim 9, wherein the one or more recently played media items are listed sequentially in the history list based on playback order.
12. The method of claim 9, wherein the toggle button is displayed within a header window of the GUI, wherein the toggle button remains hidden from view until a user pointing device is within the header window of the GUI.
13. The method of claim 9, wherein the toggle button is displayed within a header window of the GUI, wherein the toggle button remains within a fixed position in the header window of the GUI.
14. The method of claim 9, wherein the one or more recently played media items in the history list are each displayed concurrently with one or more action buttons, wherein the one or more action buttons include purchase, play now, play next, add to queue, or a combination thereof.
15. A system, comprising:
- one or more processors; and
- one or more computer readable media comprising computer readable code executable by the one or more processors to: causing to display a graphical user interface (GUI) depicting a toggle button and at least one of a queue representing a playback sequence of one or more media items and a history list separate from the queue representing one or more recently played media items; in response to receiving a selection of the toggle button, toggle display between the queue and the history list; and in response to receiving a selection of at least one media item in the history list, adding the at least one media item to the queue.
16. The system of claim 15, further comprising computer readable code executable by the one or more processors to:
- in response to a determination that a recently played media item meets a first criterion, adding the recently played media item to the history list;
17. The system of claim 16, wherein the first criterion comprises a minimum play time parameter of the recently played media item.
18. The system of claim 16, wherein the first criterion comprises full playback of the recently played media item.
19. The system of claim 15, wherein the one or more recently played media items are listed sequentially in the history list based on playback order.
20. The system of claim 15, wherein the toggle button is displayed within a header window of the GUI, wherein the toggle button remains hidden from view until a user pointing device is within the header window of the GUI.
21. The system of claim 15, wherein the one or more recently played media items in the history list are each displayed concurrently with one or more action buttons, wherein the one or more action buttons include purchase, play now, play next, add to queue, or a combination thereof.
Type: Application
Filed: Feb 14, 2023
Publication Date: Sep 28, 2023
Inventors: Christopher John Sanders (San Jose, CA), Anne Jones (Emerald Hills, CA), Jeffrey L. Robbin (Los Altos, CA), William Martin Bachman (San Jose, CA), Timothy B. Martin (Sunnyvale, CA)
Application Number: 18/169,064
