Method for managing a media library, corresponding system and computer program product

Abstract

Embodiments of the present disclosure relate to methods for managing a media library, corresponding systems, and computer program products. According to an embodiment, a method for managing an automotive infotainment media library, wherein media content files originate from a set of source devices, and the media content files can be accessed by at least one media player application having multiple configurations via corresponding playback paths, the method comprising: parsing the media content files in the media library to create at least one index table, the index table comprising a corresponding list of identifiers associated with the media content files, wherein the media content files are parsed according to at least one source device in the set of source devices, parsed according to one of multiple configurations of at least one media player application, or parsed according to a folder that groups the media content files in the media library.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of Italian Patent Application No. 102020000005143, filed on March 11, 2020, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] This specification relates to managing media libraries, corresponding systems, and computer program products. Background Art

[0004] Over the past few years, infotainment systems used in the automotive industry have gone far beyond traditional car radios and car audio systems and have been the subject of improvement and development.

[0005] Accordo provided by STMicroelectronics TM The devices of the TU-1000 series and the eT-Kernel RTOS board support package (eT-Kernel is a standardized product of eSOL for the uITRON RTOS) are examples of such developments for infotainment systems in the automotive industry.

[0006] The so-called Media Library (ML) application is part of a middleware layer in a software turnkey solution coupled with a Media Player Application (MPA) in infotainment systems for the automotive industry. The operation of a media player (an audio player reproducing a song may be referred to by way of non-limiting example) in such a system is based on a file system path to the song, which can be played (reproduced) via various possible file system mount points.

[0007] Various types of devices (such as USB devices, Secure Digital Multimedia Cards (SDMMC), NAND memories, in-app (iAP) purchase devices, Media Transfer Protocol (MTP) devices, or RAM disks) are (non-limiting) examples of such devices that can provide specific media content to a user once a path to the content is provided via the file system.

[0008] Regardless of the source involved, the media player is able to make media content (e.g., playing songs) available in a customized manner, for example, sorted by specific criteria, with a specific purpose, and in an extensible manner, i.e., providing an increasing number of features depending on the amount of memory available in the system. The media player can be controlled by a high-level client application layer. The media library is able to provide a set of high-level application program interfaces (APIs) to manipulate files according to client specifications, a required feature for such infotainment systems.

[0009] It should be noted that in the context considered herein, the name "customer" primarily refers to the manufacturer / installer of the infotainment system, whereas the name "user" applies, for example, to the (end) user of the system, such as a car driver / passenger.

[0010] Especially in entry-level systems, optimizing (and reducing) the bill of materials (BOM) is a desirable goal pursued by customers. Reducing the BOM specification usually involves a reduction (or even complete removal) of external memory support, which inevitably affects the available space for software applications (mainly middleware). For example, some conventional arrangements may include only 1.2Mbyte of (internal) RAM space, while other traditional solutions rely on only a few Mbytes for media management and associated databases (DB).

[0011] Indeed, being able to provide customized views of media content (with the client's own "flavor") is a desirable feature. Furthermore, clients (and users) reasonably expect that system performance should not degrade below certain levels: for example, a certain song (whether the "first" song or the next / previous song desired to be reproduced) should be reproduced without undue delay perceived by the user.

[0012] Some media library engines maintain a database of complete song paths in volatile memory by way of example. This approach also involves maintaining a database manager (e.g., Structured Query Language or SQL) in volatile memory. The corresponding increase in volatile memory space dedicated to media library storage inevitably translates into an increase in BOM, which may be unacceptable for many applications. Summary of the invention

[0013] According to an embodiment, a method for managing an automobile infotainment media library includes media content files originating from a collection of source devices, wherein the media content files can be accessed by at least one media player application via a corresponding playback path, and at least one media player has multiple configurations. The method includes: parsing the media content files in the media library to create at least one index table, the index table including a corresponding list of identifiers associated with the media content files, wherein the media content file is parsed according to at least one source device in the original device in the collection of source devices, parsed according to one of the multiple configurations of at least one media player application, or parsed according to a folder that groups the media content files in the media library; and activating at least one media player application to access the media content file via the corresponding playback path, the media content file having an identifier associated with it that is listed in the at least one index table.

[0014] According to another embodiment, a management system for an automotive infotainment media library, the automotive infotainment media library including media content files originating from a collection of sources, the system including: a parser circuit device, configured to parse the media content files in the media library to create at least one index table, the at least one index table including a corresponding list of identifiers associated with the media content files, the media content files being parsed according to at least one source device in the collection of source devices, and / or parsed according to one of multiple configurations of at least one media player application, and / or parsed according to a folder in which the media content files are arranged in the media library; a memory circuit, for at least temporarily storing at least one index table; a browser circuit, for retrieving the media content files in the media library via a corresponding playback path, and providing the media content files in the media library to at least one media player application, the media content files having identifiers associated therewith listed in at least one index table.

[0015] According to another embodiment, a non-transitory computer-readable medium has instructions stored thereon, which, when executed by a processor, cause the processor to manage a car infotainment media library by performing the following steps, the car infotainment media library including media content files originating from a collection of source devices, the steps including: parsing the media content files in the media library to create at least one index table, the index table including a corresponding list of identifiers associated with the media content files, wherein the media content files can be accessed via a corresponding playback path by at least one media player application, the at least one media player application having multiple configurations, and wherein the media content files are parsed according to at least one source device in an original device in the collection of source devices, according to one of the multiple configurations of the at least one media player application, or according to a folder that groups the media content files in the media library; and activating at least one media player application to access the media content files via the corresponding playback path, the media content files having identifiers associated therewith listed in the at least one index table. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] One or more embodiments will now be described by way of example only with reference to the accompanying drawings, in which:

[0017] Figure 1 are general illustrative examples of possible contexts of use of embodiments,

[0018] Figure 2 is an exemplary block diagram of a possible usage environment of an embodiment;

[0019] Figure 3 is a functional exemplary block diagram of a possible embodiment;

[0020] Figure 4 is a functional exemplary block diagram of the operation of a parser included in an embodiment according to the present specification,

[0021] Figure 5 is a functional exemplary block diagram of the operation of a browser included in an embodiment according to the present specification,

[0022] Figure 6 is an example of a file system tree according to an embodiment of the present specification,

[0023] Figure 7 and Figure 8 is an exemplary parsing sequence according to an embodiment of the present specification, and

[0024] Fig. 9 is an example of a table that may be generated in accordance with an embodiment of the present specification. DETAILED DESCRIPTION

[0025] In the following description, one or more specific details are described to provide a deeper understanding of the examples of the embodiments of the present description. The embodiments may be obtained without one or more specific details, or by other methods, components, materials, etc. In other cases, known structures, materials, or operations are not described or illustrated in detail so that certain aspects of the embodiments are not obscured.

[0026] In the framework of this specification, references to "an embodiment" or "an embodiment" are intended to indicate that a particular configuration, structure, or feature described with respect to that embodiment is included in at least one embodiment. Therefore, phrases such as "in an embodiment" or "in an embodiment" that may appear in one or more points of this specification do not necessarily refer to one or more of the same embodiments. In addition, specific configurations, structures, or features may be combined in any suitable manner in one or more embodiments. The titles / references used herein are provided merely for convenience and do not limit the scope of protection or the scope of the embodiments.

[0027] Some embodiments of the present invention help provide an improved media library management solution that can fully respond to customer expectations while keeping BOM specifications within the boundaries of compatibility with infotainment applications in the automotive industry. One or more embodiments can be applied to real-time operating system (RTOS) media player applications used in the automotive infotainment industry.

[0028] One or more embodiments may relate to a corresponding computer program product loadable in a memory of at least one processing circuit (e.g., a computer) and comprising software code portions for performing the steps of the method when the product is run on the at least one processing circuit. As used herein, reference to such a computer program product is understood to be equivalent to reference to a computer-readable medium containing instructions for controlling a processing system in order to coordinate the implementation of the method according to one or more embodiments. Reference to "at least one computer" is intended to emphasize the possibility of implementing one or more embodiments in a modular and / or distributed form.

[0029] One or more embodiments may provide a media library engine suitable for implementation in a scalable manner with reduced memory requirements: as a non-limiting example, a collection of index tables of only two bytes may present possible views of an infotainment system that a user could manage, for example, 65.536 songs per media player.

[0030] In one or more embodiments, the index is kept in place of the complete part, folder name, and file name. For example, in one or more embodiments, the path to the content to be played (rendered) can be built "on-the-fly", such as via an optional caching system, and possibly querying the file system when needed.

[0031] In one or more embodiments, the tables may be transferred (swapped) to non-volatile memory so they do not need to be created at each platform boot.

[0032] One or more embodiments may include fast and delayed callback mechanisms to facilitate achieving good performance levels.

[0033] One or more embodiments may also provide multi-lingual support for languages ​​using non-Latin characters, such as disclosed in Italian patent application 102018000002537.

[0034] Figure 1 is an example of a vehicle (eg, a motor vehicle such as a motor car) equipped with the infotainment system 100 .

[0035] The system 100 may include a collection of devices D1, D2, ..., Dn, which are intended to act as a source of media content (e.g., audio / video). Such content is intended to be provided to a user (a driver or one or more passengers in a vehicle V) upon command (possibly including voice command), which is applied by such user at the control unit 102. The devices D1, D2, ..., Dn may include a variety of different devices: the non-limiting list of devices already discussed above (USB, SDMMC, NAND, iAP, MTP, RAM disk devices) are examples of such devices.

[0036] For simplicity and ease of understanding, the following description will mainly refer to audio / sound content (e.g., songs) that need to be reproduced via an audio system, such as Figure 1 A schematic example of a loudspeaker at 104 is shown.

[0037] For example, associated video content (the title of the song being played, the performing artist, related albums, genres, just as possible examples) may also be displayed on the display unit 102A of the control unit 102. Again, it should be understood that references to audio content (and to the underlying video content that may be associated therewith) should not be interpreted in a limiting sense of the embodiments, even indirectly. In fact, the embodiments can be applied to any type of media content and are primarily related to the structure and operation of the (substantially SW-based) media library management engine 10.

[0038] The basic purpose of the engine 10 as described herein is to coordinate the operation of the various parts of the infotainment system 100 so that certain media content (e.g., songs) originating from any one of the devices D1, D2, ..., Dn can be transmitted (e.g., played at 104) in accordance with the commands applied by the user at 102.

[0039] Figure 2 is an exemplary block diagram of an "ecosystem" surrounding a media library management system (hereinafter referred to as an "engine" for simplicity) as contemplated herein. Figure 2 At the bottom of the figure, devices D1, D2, ..., Dn-1, Dn are represented together with the associated file system FS and virtual file system VFS (the virtual file system VFS may involve the operation of source devices such as iAP devices and MTP devices).

[0040] As known to those skilled in the art, how the data in the file system control library (database) is stored in order to call (retrieve), the data has an independent collection of data, is designated as "file", and may be grouped in a "folder". The file system specifies the structure and logical rules for managing files. As illustrated in this article, the file system FS (and possible virtual file system VFS) can provide access to media (such as audio and video) in a formatted manner. It should be understood that devices D1, D2, ..., Dn-1, Dn and possible file systems FS, VFS can be different elements about the engine 10 of the embodiment.

[0041] from Figure 2 Starting at the top left of FIG. 1 , reference 12 is an example of a "basic" media player application (MPA). This could be any known type of MPA, which could include customer "flavors", i.e. features intended to be specific to certain customers.

[0042] Note again that as used herein, "customer" refers to the manufacturer / installer of the engine 10 / system 100, who may desire the engine / system to include specific features that are unique to that customer.

[0043] To this end, the basic MPA 12 may rely on a set of additional services provided by specific additional layers. This may be the case, for example, for file and folder operations.

[0044] As used herein, a file represents a specific file of media content (e.g., a specific song), and the specific file can be considered to be included in a folder (e.g., a playlist designed by / for a specific user), so that engine 10 can manage different folders, for example, including different playlists for different users.

[0045] In an embodiment as described herein, the engine 10 may include (as a non-mandatory feature) an autonomous MPA, designated 12A, which may be configured to, for example, request a path to a certain next / previous content (a certain song, for example) from a media library manager block 14 (discussed below), in addition to registering the media with the media library manager's framework and setting a sorting mode (discussed below).

[0046] A high-level MPA designated 12B (which may also include custom "flavors") may rely on the low-level layers of the media library for media and file ID operations. As noted, a high-level MPA may not be a mandatory feature of an embodiment; if present, it may integrate some of the services considered herein as belonging to the media library manager block designated 14.

[0047] As described herein, the media library manager block 14 is intended to combine a collection of low-level services as exemplified by block 16, while also being responsible for starting the media parser 18, as described below. In this way, the media library manager block 14 can cooperate with the media library interface block 20. This is intended to rely on the media library manager 14 and the media library services 16 to provide additional manipulation services for MPA applications (especially the base type 12) that have not yet integrated complete logic for this purpose.

[0048] Reference 22 represents a media library cache (which may be referred to as an "L1" cache) that may be provided to cooperate with the media library manager block 14 to reduce latency when retrieving a particular media content (song) path by relying on a collection of x-paths stored in the cache memory 22. Finally, reference 24 represents another cache memory that may be provided to support the media library services block 16 and the parser 18 (e.g., used as an "L2" cache memory that acts as a file and folder cache).

[0049] As shown herein, the media library parser 18 may be configured to perform media parsing (in a manner that is transparent to any "flavor" in the media player application) as described below.

[0050] The parser block 18 is intended to build index tables (eg, IT0, IT1, IT2, IT3 as discussed below) and provide feedback to the various MPAs when parsing certain media content.

[0051] As described below, possible notifications from the parser 18 to the MPA may include: a first callback message (a "quick" callback): this indicates that (only) a certain number of (a subset of) media content files have been parsed and sorted in a certain way; a second callback message (a "standard" callback): this indicates that all media content files in the library have been parsed in a certain way; and a third callback message (a "delayed" callback): this indicates that the media content files have also been parsed with respect to possible tags (e.g., applied by a user to certain media content).

[0052] Figure 2 The right side of shows a possible arrangement of index tables, each index table comprising a specific list of media content (eg, songs with corresponding identifiers ID0, ID1, ID2, ..., IDn).

[0053] These index tables (ITX, typically, X=0, 1, 2 and 3 are considered here) may include, for example: IT0: index table 0 of media x with sorting type A (provided by any device D1, ..., Dn); IT1: index table 1 of media x with sorting type B (provided by any device D1, ..., Dn); IT2: index table 2 of media y with sorting type A (provided by any device D1, ..., Dn); and IT3: index table 3 of media y with sorting type C (provided by any device D1, ..., Dn).

[0054] Combined with the following Figures 6 to 8 As described above, the index table (such as IT0, ..., IT3) can conform to the dynamic folder description chain table (such as Figure 2 As shown in the lower right corner), the "root" folder 0RF0 with the related feature F0' can point to other folders F1, F2 through the corresponding features F1' (from RF0 to F1) and F2' (from F1 to F2).

[0055] Figure 3 is a functional block diagram representation of the engine 10, with a stack of applications reproduced on the left side of the figure, including: communicating with a media player 122 (see also) via a media player application player interface (API) 122A. Figure 1 104) interface with the infotainment (car radio) application 120; via the media library API 124A and the media library 124 interface media player 122; via the file system API 126A and the file system 126 interface (see Figure 2 and a file system 126 configured to control any device D1, ..., Dn (here designated as 128, an example being a USB stick or key) via a device driver and controller 128A.

[0056] like Figure 3 As shown, the parser 18 is configured to retrieve file and folder attributes based on the file system 126 and create index tables IT0, ..., IT3 therefrom.

[0057] like Figure 3 As shown, the parser 18 is instantiated by the media library 124, which can also instantiate the browser 26, which is configured to read the index tables IT0, ..., IT3 and return the media content delivery path (e.g., the path to individual media files such as songs) to the media player 122.

[0058] like Figure 3As shown, the parser 18 may be configured to inform the media player 122 of the extent of parsing completed at a certain point in time, such as by sending the media player fast, standard, and delayed callback messages as discussed above.

[0059] Figure 4 is an example of a possible media library flow, focusing on the tasks performed by the parser 18. Figure 4 In block 181, a new media source (e.g., a new device D1, ..., Dn) is coupled to the media library framework and registered by the MPA as such an example (e.g., it can be considered Figure 2 12).

[0060] Once new media is queued, the parser 18 may begin parsing the new media content as soon as it is available for that purpose, as shown at 182 .

[0061] Figure 4 Block 183 in is an example of a sorted index table created by the parser and populated into the cache, such as Figure 2 As shown in 24.

[0062] For example, Figure 4 As shown in the lower part of , this may involve forming a (first) index table ITX for media y by creating a list of content (for example) identified by corresponding identifiers ID0, ID1, ..., IDn with some type of ordering (for example, typically designated as type a).

[0063] A corresponding folder FX descriptor with certain features FX′ may also be created, and these data are stored in the cache memory space, as shown in 24 .

[0064] As previously described, once the first (sub)set of songs (media content) is processed, a quick callback may be sent to the media player 122 (see Figure 3 ), as shown at 184, so that the MPA controlling the media library is informed of the possibility of browsing and playing the collection of songs - that is, more generally, as shown at block 185, the possibility of reproducing the first collection of media files in any possible order (excluding tags, as described below).

[0065] Block 186 is an example of the parser 18 completing the parsing task, which results in the newly added media content being fully parsed and, as discussed previously, sending a corresponding callback message to the media player 122. In this way, the responsible MPA is informed of the possibility of browsing and reproducing all media content (e.g., playing all songs) in any possible way, which media content can be sorted (again in addition to tags).

[0066] Block 187 is an example of the (non-mandatory) possibility for the parser 18 to restart parsing the newly added media for tag sorting. To avoid adversely affecting system performance, such a process may be performed at a later stage and with a lower priority relative to other tasks.

[0067] Block 188 is an illustrative example of this possible additional (tag) parsing, which has been completed by a delayed callback message sent to the MPA level. Thus, as shown at 189, the MPA responsible for management suggests the possibility of browsing and reproducing all media content files (e.g., playing songs) by considering the tag instances.

[0068] Figure 5 is another functional block diagram example of the Media Library process, emphasizing Figure 3 The role of browser 26.

[0069] Block 261 is an example of a browser task 26 waiting for a callback from the media library framework (e.g., by Figure 3 After the media library 124 in the browser 26 is instantiated).

[0070] Box 261 is an example of a possible sorting mode for the current media that the browser 26 begins at 262 (upon receiving a callback from the media library framework), which sorting mode may involve (as shown in box 263) the media library manager of the user view indicated by the browser 26 (see also Figure 2 Application of box 14).

[0071] For example, as shown at 264, the browser 26 may request to reproduce the previous / next media content file (eg, song), as shown at 265, which may result in retrieving the path of the media content file (eg, song) to be reproduced in the media library manager.

[0072] As shown herein, this may be accomplished via index tables (such as IT0, ..., IT3) created by the parser 18 along the lines discussed above, and via associated caches (such as 24) and file systems (such as Figure 2 It is implemented by FS and VFS in .

[0073] Thus, as shown at 266, the media player application - now knowing the path provided by the browser 26 - can access the media content (song) via the path indicated by the browser and provide delivery of the media content (e.g., play the selected song).

[0074] Figure 6is an exemplary example of a possible use of an index by the parser 18 with reference to a (purely exemplary) situation of a file system tree associated with a (purely exemplary) situation of a media content file: arranged in four folders, namely a root folder identified as 0 plus three (sub)folders, namely folder_a, folder_b and folder_c, in Figure 6 Identified as 2, 3 and 1 in the figure; it includes seven different files (e.g., songs), which are designated as file_a (file_a), file_b (file_b), file_c (file_c), file_d (file_d), file_e (file_e), file_f (file_f) and file_g (file_g).

[0075] Figure 6 An example of sorting media files (e.g., songs) by file name could be, for example, taking into account six characters in the name. Of course, the number of characters taken into account is configurable. Furthermore, the order of folders (root, folder_a, folder_b, folder_c) and files (file_a to file_f) could be completely independent of the numbering shown.

[0076] In one or more embodiments, the parser 18 may actually perform a sort through the intermediate table in order to create an index table. Each time a folder is considered, some auxiliary information may be (optionally) collected to quickly browse the three folders without accessing the file system each time.

[0077] Figure 7 is an illustrative example of a sequence of steps numbered I to VIII involving (as an example) generating a middleware index table sorting the file names of each media (ie for the specific devices D1, ..., Dn in the example considered).

[0078] Figure 7 Steps I through VIII in are examples of the following behavior:

[0079] I: Find the first file in the media library (i.e., the first song, specified here as file_f), and assign it an identifier ID1; insert the corresponding record into the temporary table;

[0080] II: Find the second file (e.g. file_c) and assign it identifier ID2; add the corresponding record to the table sorted by file name;

[0081] III: The same previously discussed behavior is performed for the third file i.e. file_d and the records are added to the table (sorted by file name, in the example considered) such that file_d with ID3 is added to the table between file_f (ID1) and file_c (ID2), i.e. the index order is not followed;

[0082] IV: For file _e assigned identifier ID4, repeat the behavior discussed above and add the record to the table, again assuming sorting by file name, regardless of the order of ID numbers;

[0083] V: For file _b assigned identifier ID6, repeat the behavior discussed above and add the record to the table, again assuming sorting by file name, regardless of the order of ID numbers;

[0084] VI: For file _g assigned identifier ID5, repeat the behavior discussed above and add the record to the table, again assuming sorting by file name, regardless of the order of ID numbers;

[0085] VII: For file_a assigned identifier ID7, repeat the behavior discussed above and add records to the table, again assuming sorting by file name, regardless of the order of ID numbers; and

[0086] VIII: Get the final index table ITX (sorted by file and name) (see Figure 3 Tables IT0 to IT4 in the table are for reference).

[0087] Once completed (step VII), the (final) index table ITX can be created (step VIII) by copying the first column of the temporary table, so that the temporary table and the associated memory space are available for further use, and the final index table of step VIII is saved in a volatile memory or transferred to a non-volatile memory, such as a cache memory 24.

[0088] Figure 8 is an example of the possibility of providing an index table ITX' (again referring to Figure 6 The file system tree described in Figure 7 The index table ITX in step VIII is obtained by sorting the file names of each folder, in contrast (assuming that it is obtained by sorting the file names of each medium).

[0089] Folder descriptors (e.g., folder descriptor ID2) may be selectively maintained in a linked list, which may facilitate quick navigation of system three and provide information about system three to upper-level applications without accessing the file system each time.

[0090] For example, the tables A, B and C reproduced below are examples of the possibility of associating a certain value with these values ​​saved in a memory (volatile or non-volatile) as a table to a certain descriptor (description) of a folder, such as Fig. 9 shown.

[0091] Table A

[0092] Description (not in table) value Base folder / number 2 Parent folder / number 0 Subfolders / Number 3 Folder / number 1 Folders / Number 0 Minimum number of subfolders 3 Number of files 3

[0093] Table B

[0094] Description (not in table) value Number of folders 1 Number of playlists 0 First subfolder 3 Base folder depth 1 The first file in the folder 4 First playlist in folder 0 The next folder ID to sort 3

[0095] Table C

[0096]

[0097]

[0098] In this way, the descriptor / description is not listed in the table, but can be found by referencing the value listed in the table. This allows for great efficiency when keeping records for each folder.

[0099] Regardless of the criterion used for sorting, index tables (such as ITX, ITX' (such as Figure 3 The index tables shown in IT0, IT1, IT2, and IT3 in the media library manager (see Figure 2 14) Visit Figure 2 16 in the media library service, as previously described. Caching relevant data can help avoid too frequent accesses to the file system to retrieve the path to a particular media content (e.g., a song to be played, with possibly associated graphical information such as a song title) by communicating the path to the media player application so that the associated file can be accessed ("opened") and the associated media content made available (e.g., the corresponding song is played by the media player).

[0100] One or more embodiments help achieve an appropriate tradeoff between the memory area involved and the performance level.

[0101] One or more embodiments may be configured (customized) according to parameters such as:

[0102] Supported media (including iAP, MTP, CD-TEXT for audio CDs)

[0103] The number of files / folders / playlists per media (e.g., the parser 18 may stop when a maximum number is reached)

[0104] For example, tag extraction is activated for MP3, WMA, FLAC, WAW, M4A, OGG, MP2, AIGG file formats.

[0105] Activation of image (original image) extraction in formats such as JPG, BMP, P,

[0106] Media library interface activation for basic media player applications,

[0107] Format playlists such as XSFP, PLS, M3U, WPL, ASX support activation,

[0108] Maximum file / folder path length,

[0109] The maximum number of characters per tag instance (e.g., author, artist, album, title, genre, comment, year),

[0110] Maximum number of characters in CD-text,

[0111] Cache activation of file, folder and playlist names,

[0112] Maximum file, folder, playlist name,

[0113] Files sorted by media,

[0114] Sort files by folder,

[0115] Playlists sorted by folders,

[0116] Folders sorted by media,

[0117] Folders sorted by folder,

[0118] Sort files by playlist,

[0119] Sort by files and playlists,

[0120] The sorting of MTP and iAP devices,

[0121] Consider the number of characters to sort,

[0122] Sort by tag instances (author, artist, etc.),

[0123] Multi-language sorting,

[0124] Random range rules,

[0125] The operating mode via relative or absolute file system mode identifier.

[0126] One or more embodiments facilitate implementing media content (eg, song) management options and associated databases that consume a reduced number of bytes of (volatile) memory.

[0127] One or more embodiments demonstrate a high degree of scalability that can be applied to a set of basic and advanced features.

[0128] One or more embodiments help maintain good performance for parsing and browsing media content.

[0129] By means of features such as the introduction of an index table and the fast callback and delayed callback mechanisms discussed above, one or more embodiments help to achieve one or more of the following objectives:

[0130] Provides a "smart" media library engine with low memory consumption,

[0131] It also provides custom browsing for platforms that are exposed to memory leaks.

[0132] The ability to account for specific platform characteristics and / or specific storage device characteristics within a defined domain.

[0133] Therefore, the instant description is to manage the car infotainment media library (e.g. Figure 3 In an example of a method of 124), the automotive infotainment media library includes a collection of media from a source device (e.g., Figure 2 D1, ..., Dn or Figure 3 128), wherein the media content file can be used by at least one media player application (e.g., Figure 2 12, 12A, 12B or Figure 3 122 in ) via the corresponding playback path (e.g., see Figure 2 FS, VFS or Figure 3 126) access, at least one media player application has multiple configurations (e.g., different customer "flavors", i.e., specific engine / system features unique to the customer).

[0134] The methods exemplified herein may include: parsing (e.g., see Figure 2 and 3 18 and Figure 4181 to 189 in the above) media content files in the media library to create (generate) at least one index table (e.g., IT0, IT1, IT2, IT3 or ITX, ITX'), the table including a corresponding list of identifiers associated (i.e., assigned or allocated) with the media content files (e.g., ID0, ID1, ..., IDn), the media content file being parsed according to at least one source device in a set of source devices, and / or according to one of a plurality of configurations of at least one media player application, and / or according to a folder that groups the media content files in the media library; and activating at least one media player application to access the media content files via the corresponding playback path, the media content files having an identifier associated therewith and listed in the at least one index table (in short: the media content files listed in the at least one index table).

[0135] Reference herein to “at least one” index table is intended to emphasize the fact that, while creating (generating) multiple such tables has been discussed previously, one or more embodiments may even contemplate creating only one index table comprising a (corresponding) list of identifiers associated (assigned or allocated) with media content files (such as, for example, ID0, ID1, …).

[0136] Furthermore, it should be understood that one or more embodiments are primarily directed to providing parsing features for generating the one or more index tables discussed, rather than employing specific criteria for selecting source devices, media player configurations, or folders on which parsing is based. In fact, a fundamental advantage of one or more embodiments is that they are "transparent" to such criteria.

[0137] Regardless of the parsing standard employed, the use of index tables is advantageous because the tables represent only meta-information as opposed to the complete path that a media player would use to deliver specific content (eg, play a specific song / playlist).

[0138] For example, identifiers may be stored in the form of numbers (eg, a 16-bit number may be used to unambiguously identify more than 65,000 files) instead of corresponding paths, which consume (more) memory.

[0139] Conventional systems would take up (a lot of) memory space to store the (new) information (e.g. the path / song title, possibly in its entirety) plus the associated meta-information (how to navigate the object stored in the database). In contrast, an identifier-based system can consider only a single attribute (the meta-information) without re-storing the same information that already exists in the file system.

[0140] Thus, one or more embodiments may generate the required paths "on the fly" based on the (meta)information available at a particular time, without having to save it in memory along with the corresponding memory requirements.

[0141] As a (simple) example, generating a path might involve: evaluating the identifier (ID) of the song that is next to be played; searching via the file system for the file corresponding to that ID, and setting its path.

[0142] This task can be alleviated by the support of one or more cache memories, where at least part of the relevant information can be stored, thereby avoiding or reducing access to the file system and thus reducing the cost of path construction.

[0143] In the method illustrated herein, parsing may include a first parsing step (e.g., 182, 183) in which a first subset of media content files in a media library is parsed, the method including issuing a partial ("quick") callback message (e.g., 183) that indicates to a media player application the availability of access via corresponding playback paths of the parsed first subset of media content files, the media content files having associated therewith an identifier listed in at least one index table.

[0144] In one or more embodiments, this fast callback mechanism may result in the media player being notified that a certain, possibly configurable number of files (e.g., songs) has been analyzed. Selecting a low value for this number helps speed up the callback mechanism. The set of notified files (e.g., songs) may be presented in an unsorted fashion, or in a sorted fashion based on the set of files analyzed at the time (rather than the entire set available in the media library, which will be discovered at a later stage).

[0145] The method illustrated herein may include, as parsing of a media content file in a media library is completed (e.g., 184), issuing a complete callback message (e.g., 185) to a media player application, the complete callback message indicating to the media player application the availability of access via a corresponding playback path (e.g., 186) of the parsed media content file, the media content file having an identifier associated therewith that is listed in at least one index table.

[0146] In the method illustrated herein: the media library may include media content files tagged via corresponding tags; parsing may include performing tag-based parsing of media content files listed in multiple index tables (e.g., 187); and the method may include, as a result of the tag-based parsing being completed, issuing a further ("delayed") callback message (e.g., 188), the further callback message indicating to the media player application the availability of access via the corresponding playback path of the media content file, the media content file having an identifier associated therewith listed in at least one index table, the media content file also being parsed based on the tag.

[0147] Again, one or more embodiments are primarily concerned with the possible provision of parsing features based on tags, rather than the specific nature of those tags, to convey additional information available in the media content file. Such information may include (by again referencing a song as a non-limiting example of a media content file) author, album, genre, script, etc.

[0148] Software-based extractors (known to those skilled in the art) can be used to extract this information by "opening" and processing the file. This may result in an undesirable reduction in parsing speed. Therefore, it may be advantageous to resort to a low-priority "deferred" callback.

[0149] In the method illustrated herein, accessing media content files in a media library may include browsing (e.g., 26) media content files having an identifier associated therewith and listed in at least one index table, wherein browsing may include: through a current media content file, retrieving (via an identifier associated therewith: see, e.g., 265) a previously accessed media content file or any one of the next media content files scheduled to be accessed in at least one index table, and providing (e.g., 266) a playback path to a previously accessed media content file or any one of the previous or next media content files in the media library to a media player application, wherein the current media content file has an identifier associated therewith and listed in at least one index table being accessed.

[0150] In the methods exemplified herein, parsing may include creating a linked list (eg, ITX') of folder descriptors in at least one index table to facilitate accessing parsed content files in the media library without accessing a file system of the media library.

[0151] The method illustrated herein may include storing at least one index table in volatile memory, and in view of a planned decommissioning of the media library, transferring at least one index table to non-volatile memory, wherein the at least one index table is retained for a subsequent restart of media library operation.

[0152] As shown in this example, a management system (e.g., 10) for a car infotainment media library includes media content files originating from a collection of source devices, wherein the media content files can be accessed by at least one media player application having multiple configurations via corresponding playback paths, and can be configured to implement the method described herein, and includes:

[0153] a parser circuit device (e.g., support SW) configured to parse media content files in the media library to create at least one index table, the at least one index table comprising a respective list of identifiers associated with the media content files, the media content files being parsed according to at least one original device of the source devices in the set of source devices and / or parsed according to one of a plurality of configurations of at least one media player application and / or parsed according to a folder in which the media content files are arranged in the media library;

[0154] memory circuitry (e.g., 24) for at least temporarily storing at least one index table; and

[0155] The browser circuit device (e.g., supporting SW) retrieves media content files in the media library via a corresponding playback path and provides the media content files in the media library to at least one media player application, wherein the media content files have identifiers associated with them and listed in at least one index table.

[0156] As described herein, a computer program product loadable in a management system for managing an automotive infotainment media library may include software code portions for implementing the steps of the method described herein.

[0157] In various embodiments, the methods described herein may be implemented at least in part using a processor coupled to a non-transitory computer-readable medium (e.g., a memory). The non-transitory computer-readable medium may include instructions that can be executed by the processor to implement the embodiment algorithm. The processor may include a central processing unit (CPU), a microprocessor, a microcontroller, or other processing circuitry known in the art that can execute machine-readable instructions. In alternative embodiments, dedicated digital logic, programmable digital logic such as a field programmable gate array (FPGA), a digital signal processor (DSP), or other suitable digital hardware may be used to implement the methods described herein.

[0158] Without prejudice to the essential principles, the details and embodiments may vary, even significantly, with respect to what is described purely by way of example, without departing from the scope of protection.

Claims

1. A method of managing an automotive infotainment media library, the automotive infotainment media library comprising media content files originating from a collection of source devices, wherein the media content files are accessible by at least one media player application via corresponding playback paths, the at least one media player application having a plurality of configurations, the method comprising: Retrieving a path name of the media content file from a file system; parsing the media content files in the media library to create at least one index table including a respective list of digital identifiers associated with the path names of the media content files, wherein the media content files are parsed according to at least one source device in the set of source devices, according to one of the plurality of configurations of the at least one media player application, or according to a folder grouping the media content files in the media library, the at least one index table including a first index table including the digital identifiers in a first order and excluding the associated path names; storing the pathname of the media content file in a cache memory separate from the file system; storing the first index table in a volatile memory separate from the file system and distinct from the cache memory; retrieving from the cache memory a first path name associated with a first numeric identifier included in the first index table; providing the retrieved first path name to the at least one media player application without accessing the file system; as well as The at least one media player application is activated to access media content files via corresponding playback pathways, the media content files having associated therewith the digital identifier listed in the at least one index table.

2. The method according to claim 1, wherein: The parsing comprises: parsing a first subset of the media content files in the media library in a first parsing step; and The method also includes issuing a partial callback message to the at least one media player application, the partial callback message indicating to the media player application the availability of access via corresponding playback paths of the first subset of parsed media content files, the parsed media content files having associated therewith the digital identifier listed in the at least one index table.

3. The method according to claim 1, further comprising: As the parsing of the media content files in the media library is completed, a complete callback message is issued to the at least one media player application, the complete callback message indicating to the media player application the availability of access via a corresponding playback path of the parsed media content files, the parsed media content files having associated therewith the digital identifier listed in the at least one index table.

4. The method according to claim 3, wherein: The media library includes media content files marked by corresponding tags; The parsing includes: performing tag-based parsing on the media content files listed in the at least one index table; and The method further includes issuing a further callback message as a result of the tag-based parsing being completed, the further callback message indicating to the media player application the availability of access via a corresponding playback path of a media content file having the digital identifier associated therewith and listed in the at least one index table, the media content file also being parsed based on the tag.

5. The method according to claim 1, wherein: Accessing the media content files in the media library includes browsing the media content files having the digital identifiers associated therewith listed in the at least one index table; and The browsing includes: retrieving a previously accessed media content file or a next media content file planned to be accessed in the at least one index table through a current media content file, and providing a playback path to the previously accessed media content file or one of the next media content files in the media library for the at least one media player application, wherein the current media content file has a digital identifier associated with it that is one of the digital identifiers listed in the at least one index table being accessed.

6. The method according to claim 1, wherein the parsing comprises: A linked list of folder descriptors is created in the at least one index table to facilitate accessing the parsed media content files in the media library without accessing the file system of the media library.

7. The method according to claim 1, further comprising: storing the at least one index table in a volatile memory; as well as In view of a planned decommissioning of the media library, the at least one index table is transferred to a non-volatile memory, wherein the at least one index table is retained for a subsequent restart of the media library operation.

8. A management system for an automotive infotainment media library, the automotive infotainment media library comprising media content files originating from a collection of source devices, the system comprising: a parser circuit arrangement configured to retrieve the path names of the media content files from a file system, parse the media content files in the media library to create at least one index table, the at least one index table comprising a respective list of digital identifiers associated with the path names of the media content files, the media content files being parsed according to at least one source device in the set of source devices and / or according to one of a plurality of configurations of at least one media player application and / or according to a folder in which the media content files are arranged in the media library, the at least one index table comprising a first index table comprising the digital identifiers in a first order and excluding the associated path names; cache memory circuitry configured to store the pathname of the media content file in a cache memory separate from the file system; volatile memory circuitry, separate from the file system and distinct from the cache memory, the volatile memory circuitry configured to store the first index table in volatile memory; as well as A browser circuit device is configured to retrieve a first path name associated with a first digital identifier included in the first index table from the cache memory via a corresponding playback path, provide the retrieved first path name to the at least one media player application without accessing the file system, and provide a media content file in the media library to the at least one media player application, the media content file having the digital identifier associated therewith and listed in the at least one index table.

9. The management system of claim 8, wherein the parser circuit device is further configured to: In a first parsing step, a first subset of the media content files in the media library is parsed; and A partial callback message is issued to the at least one media player application, the partial callback message indicating to the media player application the availability of access via corresponding playback paths of the first subset of parsed media content files, the parsed media content files having associated therewith the digital identifiers listed in the at least one index table.

10. The management system of claim 8, wherein the parser circuit device is further configured to: As the parsing of the media content files in the media library is completed, a complete callback message is issued to the at least one media player application, the complete callback message indicating to the media player application the availability of access via a corresponding playback path of the parsed media content files, the parsed media content files having associated therewith the digital identifier listed in the at least one index table.

11. The management system according to claim 10, wherein: The media library includes media content files marked by corresponding tags; The analytical circuit device is further configured to: performing tag-based parsing of the media content files listed in the at least one index table, and As a result of the tag-based parsing being complete, a further callback message is issued, the further callback message indicating to the media player application the availability of access via a corresponding playback path of a media content file having associated therewith the digital identifier listed in the at least one index table, the media content file also being parsed based on the tag.

12. The management system according to claim 8, Accessing the media content files in the media library includes: browsing the media content files having associated therewith the digital identifiers listed in the at least one index table; as well as The browsing circuit device is also configured to: retrieve a previously accessed media content file or a next media content file planned to be accessed in the at least one index table through a current media content file, and provide a playback path to the previously accessed media content file or one of the next media content files in the media library for the at least one media player application, wherein the current media content file has a digital identifier associated with it that is one of the digital identifiers listed in the at least one index table being accessed.

13. A management system according to claim 8, wherein the parsing circuit device is also configured to create a linked list of folder descriptors in the at least one index table to facilitate access to the parsed media content files in the media library without accessing the file system of the media library.

14. The management system according to claim 8, wherein the management system further comprises: The non-volatile memory, wherein the management system is further configured to: storing the at least one index table in the volatile memory, and In view of a planned decommissioning of the media library, the at least one index table is transferred to a non-volatile memory, wherein the at least one index table is retained for a subsequent restart of the media library operation.

15. A non-transitory computer readable medium having instructions stored thereon, which, when executed by a processor, cause the processor to manage a car infotainment media library comprising media content files originating from a collection of source devices by performing the following steps: Retrieving a path name of the media content file from a file system; parsing the media content files in the media library to create at least one index table, the index table comprising a respective list of digital identifiers associated with the path names of the media content files, wherein the media content files are accessible by at least one media player application via respective playback paths, the at least one media player application having a plurality of configurations, and wherein the media content files are parsed according to at least one source device in the set of source devices, according to one of the plurality of configurations of the at least one media player application, or according to a folder grouping the media content files in the media library, the at least one index table comprising a first index table comprising the digital identifiers in a first order and excluding the associated path names; storing the pathname of the media content file in a cache memory separate from the file system; storing the first index table in a volatile memory separate from the file system and distinct from the cache memory; retrieving from the cache memory a first path name associated with a first numeric identifier included in the first index table; providing the retrieved first path name to the at least one media player application without accessing the file system; as well as The at least one media player application is activated to access media content files via corresponding playback pathways, the media content files having associated therewith the digital identifier listed in the at least one index table.

16. The non-transitory computer readable medium of claim 15, wherein The analysis includes: In a first parsing step, a first subset of the media content files in the media library is parsed; as well as The instructions, when executed by the processor, also cause the processor to issue a partial callback message to the at least one media player application, the partial callback message indicating to the media player application the availability of access via corresponding playback paths of the first subset of parsed media content files, the parsed media content files having associated therewith the digital identifier listed in the at least one index table.

17. The non-transitory computer-readable medium of claim 15, wherein the instructions, when executed by the processor, also cause the processor to issue a complete callback message to the at least one media player application as the parsing of the media content files in the media library is completed, the complete callback message indicating to the media player application the availability of access via a corresponding playback path of the parsed media content files having the digital identifier associated therewith and listed in the at least one index table.

18. The non-transitory computer readable medium of claim 17, wherein: The media library includes media content files marked by corresponding tags; The parsing includes: performing tag-based parsing on the media content files listed in the at least one index table; and The instructions, when executed by the processor, also cause the processor to issue a further callback message as a result of the tag-based parsing being completed, the further callback message indicating to the media player application the availability of access via a corresponding playback path of a media content file having the digital identifier associated therewith and listed in the at least one index table, the media content file also being parsed based on the tag.

19. The non-transitory computer readable medium of claim 15, wherein: Activating the at least one media player application to access media content files in the media library via corresponding playback paths includes: browsing the media content files having the digital identifiers associated therewith listed in the at least one index table; and The browsing includes: retrieving a previously accessed media content file or a next media content file planned to be accessed in the at least one index table through a current media content file, and providing a playback path to the previously accessed media content file or one of the next media content files in the media library for the at least one media player application, wherein the current media content file has a digital identifier associated with it that is one of the digital identifiers listed in the at least one index table being accessed.

20. The non-transitory computer-readable medium of claim 15, wherein the parsing comprises: A linked list of folder descriptors is created in the at least one index table to facilitate accessing the parsed media content files in the media library without accessing the file system of the media library.

Images