JP2006146900A - Network av system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a network AV system that can reduce traffic between a server and a client when the server updates a database. <P>SOLUTION: An uploader UL first sends a request start notification indicating the start of registration requests to the server SV (1) and then sends a plurality of registration requests for music data M10 to M1n to the server SV (2). Upon receiving the plurality of registration requests from the uploader UL, the server SV registers the music data M10 to M1n in the database DB in an HDD 14 (3). After sending all the registration requests, the uploader UL sends a request completion notification indicating the completion of registration requests to the server SV (4). Upon receiving the request completion notification, the server SV sends an update notification to the audio client CL (5). <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a network AV (Audio / Video) system capable of reproducing audio or video, and more specifically, a network AV system including a server, a client connectable to the server, and an uploader connectable to the server. About.

  Recently, a network AV system using a client server system has been provided. The following prior applications 1 and 2 disclose a network AV system including a server having a database storing a large number of music data and an audio client connected via a LAN (Local Area Network). The audio client requests desired music data from the server, and in response to this, the server delivers the requested music data to the audio client. The audio client reproduces the music data distributed from the server.

  In the network AV system, new song data is registered in the server by the uploader. An uploader is a device having a function of registering song data in a server. The uploader is connected to the server via the network. When registering music data in the server, the uploader transmits a registration request to the server and further transmits music data to be registered. The server receives the registration request and registers the transmitted music data in the database. The uploader may exist alone or may be included in another device such as a server. The server that registers the song data transmitted from the uploader transmits to the audio client that the database has been updated (hereinafter referred to as update notification).

  When the audio client receives the update notification, the audio client acquires song information related to the song data stored in the server. Here, the song information is information for specifying song data such as a song name and an artist name, and does not include the song data itself. The audio client obtains song information and requests desired song data from the server based on the song information.

  Conventionally, when a plurality of song data is registered in the server by the uploader, the server transmits an update notification to the audio client every time one song is registered. In other words, the server transmits an update notification equal to the number of pieces of music data to be registered to the audio client. Therefore, the amount of communication between the audio client and the server has increased.

  Also, if the audio client receives multiple update notifications by registering multiple song data by the server, the audio client will receive a new update notification while acquiring song information in response to the update notification. Will receive. In this case, the audio client must interrupt the acquisition of the song information and re-acquire the song information again, which also promotes an increase in the amount of communication.

JP 2000-115165 A

[Prior Application 1] PCT / JP03 / 06552
[Prior Application 2] Japanese Patent Application No. 2003-290384

  An object of the present invention is to provide a network AV system that can reduce the amount of communication between a server and a client when the server updates a database.

  A network AV system according to the present invention includes a server having a database in which a plurality of contents are stored, an uploader connected to the server via the network and updating the database to the server, and connected to the server via the network. A client for receiving content selected from the server and playing the selected content. The uploader includes an update request unit and a completion notification unit. The update request means transmits one or a plurality of update requests for causing the server to update the database. The completion notification unit transmits a request completion notification to the server after the update request unit transmits one or more update requests. The server includes update means and update notification means. The update means updates the database in response to one or more update requests. After receiving the request completion notification, the update notification means transmits an update notification indicating that the database has been updated to the client. Here, updating means registering new content in the database, changing the content of the content in the database, or deleting the content in the database.

  The server of the network AV system according to the present invention does not transmit the update notification to the client until the request completion notification is received from the uploader even if the update means updates the database. Therefore, compared with a conventional network AV system that transmits an update notification every time the database is updated, the amount of communication between the server and the client during the update process can be reduced. The uploader transmits a request completion notification after transmitting one or more update requests. Therefore, even if the server continuously updates the database, it can send an update notification to the client after all the updates.

  Preferably, the client includes an acquisition unit and a request unit. The acquisition unit acquires information about the content selected when the update notification is received from the server. The requesting unit requests the server for the selected content based on the acquired information. Here, the information related to the content is information for specifying the content, not the content itself. For example, when the content is song data, the song name or artist name is information about the content.

  When the server continuously updates the database, conventionally, the client receives a new update notification while acquiring information about the content in response to the update notification. Therefore, the client had to stop acquiring information and acquire information again. Since the client according to the present invention receives an update notification from the server after the server finishes updating the database, the client does not receive a new update notification while acquiring information. As a result, the amount of communication can be reduced.

  Preferably, the uploader further includes start notification means. The start notifying unit transmits a request start notification to the server before the update request unit transmits a plurality of update requests. When the update notification means receives a request start notification, the update notification means transmits an update notification after receiving a request completion notification, and when it receives an update request without receiving a request start notification, the update means updates the database according to the update request Send update notification after update.

  When the uploader transmits an update request to the server only once, for example, when only one new content is registered in the server, if the uploader transmits a request start notification or a request completion notification, the traffic volume is rather high. It will increase. Therefore, when the uploader transmits the update request to the server only once, the server can transmit the update notification in response to the update request without transmitting the request start notification.

  Preferably, the server further includes a determination unit. The determination means determines whether or not the database has been updated. The update notification unit transmits an update notification when the determination unit determines that the database has been updated.

  In this case, even if the server receives a request completion notification, the server does not transmit an update notification if the database has not been updated. Therefore, even if the uploader transmits a request completion notification without requesting an update due to a malfunction or the like, the server does not transmit an update notification.

  The server according to the present invention includes a server having a database in which a plurality of contents are stored, an uploader connected to the server via the network and updating the database to the server, and connected to the server via the network. A server in a network AV system that includes a client that receives selected content from a server and reproduces the selected content, and includes an update unit and an update notification unit. The update means updates the database in response to the database update request transmitted from the uploader. After receiving the request completion notification for completing the update request from the uploader, the update notification means transmits an update notification indicating that the database has been updated to the client.

  Preferably, when the update notification means receives a request start notification to start an update request from the uploader, it transmits the update notification after receiving the request completion notification, and receives the update request without receiving the request start notification. In this case, the update means transmits an update notification after updating the database in response to the update request.

  The server according to the present invention can cope with a conventional uploader that does not transmit a request start notification or a request completion notification. Specifically, when an update request is received without receiving a request start notification, the server transmits an update notification to the client after receiving the update request. Therefore, in this case, an update notification can be transmitted without receiving a request completion notification.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals and description thereof will not be repeated.

1. Configuration of Network System Referring to FIG. 1, a network AV system 1 includes a server SV, an audio client CL, and an uploader UL.

  The server SV has a database DB that stores a plurality of pieces of music data M1 to Mn (N is a natural number). In response to the request from the audio client CL, the server SV distributes music data selected by the user of the audio client CL among the music data M1 to Mn in the database DB to the audio client CL.

  The audio client CL reproduces music data distributed from the server SV. The audio client CL is connected to the server SV via the LAN 10.

  The uploader UL causes the server SV to register new song data, changes the content of the song data Mn in the database DB to the server SV, or causes the server SV to delete the song data Mn in the database DB. The uploader UL is connected to the server SV via the LAN 10.

  In FIG. 1, one server SV, one audio client CL, and one uploader UL are shown, but a plurality of them may exist on the network 10.

1.2. Configuration of Server Referring to FIG. 2, server SV1 transmits signals between HDD (Hard Disk Drive) 14, CPU processing unit 20 including database management unit 16 and network protocol processing unit 18, and server SV and LAN 10. And a LAN controller 22 for transmitting and receiving. The HDD 14 stores a database DB. The database DB stores a plurality of compressed digital music data M1 to Mn. The database management unit 16 manages the HDD 14. Specifically, desired music data Mn is selected from the HDD 14 in response to a request from the audio client CL. Further, in response to a request from the uploader UL, new song data is registered in the HDD 14, song information of song data Mn in the HDD 14 to be described later is changed, or song data Mn is deleted. The network protocol processing unit 18 performs protocol processing on input / output data.

The HDD 14 stores a music list ML shown in Table 1.

Referring to Table 1, song list ML includes a plurality of song information I1 to In. The song information I1 to In is information related to a plurality of song data M1 to Mn stored in the database DB in the HDD 14. Table 2 shows details of the song information In.

  Referring to Table 2, song information In includes a file name, song name, artist name, album name, genre name, song length (time), file format, and song ID. In the file name, the full path name of the HDD 14 storing the song data Mn is recorded.

The server SV further stores client information CLI (Client Information) shown in Table 3 in the HDD 14. The client information CLI is information related to the client device (audio client CL and uploader UL).

  Referring to Table 3, “flag” in the client information CLI indicates whether or not there is a connection with the server SV. If there is a connection, “flag” is set, and if there is no connection, “flag” is reset. “Type” indicates a client type such as client CL or uploader UL. “Status” is a current status (operation state) such as playback, stop, completion, pause, fast forward, and rewind. “Stop” is a state in which playback of the selected music piece is stopped halfway in response to an operation on the audio client CL itself. “Completed” is a state in which the selected song has been played to the end. “Volume” indicates the current volume value (volume). “Productid” is a product ID (model information) assigned to each client type. The same product ID is assigned to the same type of client CL. For example, “1” is assigned to the audio client CL, and “2” is assigned to the uploader UL. “Firmwareid” is a firmware ID indicating the version of the firmware installed in the client device. “Hostname” is a client name assigned to the client device. “SongID” is a song ID for identifying a song being reproduced. “CurKey” is a list construction key necessary for creating a playlist PL which is a list of songs being reproduced. The playlist PL will be described later.

  The list construction key includes a filter type and a keyword. Filter types include title name, genre name, artist name, album name, and file name. For example, when the type of filter is an artist name, the name of the desired artist is recorded as the keyword. A desired music list ML can be created by searching the HDD 14 with a list construction key. Details are disclosed in the aforementioned prior application 1.

  When the client device is the uploader UL, “status”, “volume”, “songID”, and “curKey” in Table 3 are not registered.

1.3. Configuration of Audio Client Referring to FIG. 3, the audio client CL temporarily stores a microcomputer processing unit 28 including a network protocol processing unit 24 and a system operation unit 26, a flash memory 30, and sequentially input compressed digital music data. A memory 32 for storing and sequentially outputting, a sound processing unit 34 for decoding compressed digital music data to generate uncompressed digital music data, and a D / A converter (DAC) for converting digital music data into analog music data ) 36, and a LAN controller 38 for transmitting and receiving signals between the audio client CL and the LAN 10. The system operation unit 26 controls the entire audio client CL.

  Unlike the server SV, the audio client CL does not include an HDD for storing the song data Mn.

1.4. Configuration of Uploader Referring to FIG. 4, the uploader UL includes a CPU processing unit 40 including a request creation unit 41 and a network protocol processing unit 42, an HDD 44 that stores one or a plurality of song data to be transmitted to the server SV, A LAN controller 43 that transmits and receives signals between the uploader UL and the LAN 10 is provided. The request creation unit 41 creates an update request such as registration, change, and deletion of music data, and a request start notification and a request completion notification described later. The HDD 44 may be a memory.

2. Operation of network AV system 2.1. When Uploader Registers Multiple Song Data with Server Referring to FIG. 5, when uploader UL registers multiple song data M10 to M1n with server SV in network AV system 1 according to the present embodiment, uploader UL Transmits a request start notification to start the registration request to the server SV ((1) in the figure). Subsequently, the uploader UL transmits a registration request for a plurality of pieces of music data M10 to M1n to the server SV ((2) in the figure). At this time, the uploader UL transmits a registration request for each piece of music data. The server SV receives a plurality of registration requests from the uploader UL and registers the song data M10 to M1n in the database DB in the HDD 14 ((3) in the figure).

  The uploader UL transmits all the registration requests for the music data M10 to M1n to be registered, and then transmits a request completion notification indicating that the registration request has been completed to the server SV ((4) in the figure). The server SV receives the request completion notification from the uploader UL and transmits an update notification to the audio client CL ((5) in the figure).

  When a plurality of song data M10 to M1n are continuously registered in the server SV, the conventional server SV transmits an update notification to the audio client CL every time one song data M1n is registered. Specifically, the server SV issues an update notification after registering the song data M10, issues an update notification after registering the song data M11, and issues an update notification after registering the song data M1n. The server SV of the network AV system according to the present embodiment transmits an update notification to the audio client CL only once after registering all the music data M10 to M1n. For this reason, the amount of communication between the server SV and the audio client CL decreases. Details will be described below.

2.1.1. Connection Operation with Server When the uploader UL registers the music piece data M10 to M1n in the server SV, the uploader UL first establishes a connection with the server SV. Hereinafter, the connection process with the server SV by the uploader UL will be described, but the connection process with the server SV by the audio client CL is the same.

  Referring to FIG. 6, uploader UL generates a socket with the IP (Internet Protocol) address and command port of server SV according to TCP (Transmission Control Protocol), and requests connection to server SV using this socket (S101). . The command port is a port for receiving a command from the uploader UL to the server SV and transmitting a response from the server SV to the uploader UL. The server SV accepts connection at the command port (S251), and if the connection is successful, the process proceeds to step S103 (S102). As a result, the uploader UL establishes a connection to the command port of the server SV.

  Subsequently, the uploader UL transmits a client index request command to the command port (S103). In response to the client index request command, the server SV returns the client index from the command port to the uploader UL (S252), and the uploader UL receives this (S104). The client index request command is a command for the uploader UL to request a client index from the server SV. The client index is an identifier (ID) assigned from the server SV to the uploader UL.

  Subsequently, the uploader UL generates a socket with the IP address and push port of the server SV in accordance with TCP, and requests connection to the server SV using this socket (S105). The push port is a port for transmitting a request from the server SV to the uploader UL. The server SV accepts the connection at the push port (S253), and if the connection is successful, the process proceeds to step S107 (S106). As a result, the uploader UL establishes a connection to the push port of the server SV. However, at this time, the server SV has not yet identified whether the device connected to the push port is the uploader UL or the audio client CL. Therefore, the uploader UL transmits the client index received in step S104 to the push port of the server SV (S107). The server SV receives the client index (S254), and thereby identifies the device connected to the push port as the uploader UL.

2.1.2. Song Data Update Operation Referring to FIG. 7, when uploader UL registers song data M10 to M1n in server SV, uploader UL first transmits a request start notification to server SV (S201). The server SV receives the request start notification and performs start notification reception processing (S202). The start notification reception process is a process for confirming that the server SV has received a request start notification from the uploader UL.

  After transmitting the request start notification, the uploader UL requests the server SV to register the song data M10 to M1n (S20). At this time, the uploader UL makes an update request for each piece of music data M10 to M1n (S203). Specifically, in order to register the song data M10 to M1n in the server SV, the uploader UL makes an update request n times to the server SV (S20, S203). The server SV executes an update process every time an update request is received from the uploader UL (S204). Here, the update process is a process in which the server SV registers the song data M1n in the HDD 14 database DB.

  The uploader UL requests registration of the music data M10 to M1n (S20), and then transmits a request completion notification to the server SV (S205). After receiving the request completion notification, the server SV executes a completion notification reception process (S206). Specifically, when the server SV receives the request completion notification, the server SV determines that the update request from the uploader UL has been completed, and notifies the audio client CL and the uploader UL that the database DB has been updated (update notification). Transmit (S206). The audio client CL and the uploader UL each receive an update notification (S207, S208). Details of the start notification reception process in step S202, the update request process in step S203, the update process in step S204, and the completion notification reception process in step S206 will be described below.

[Start notification reception processing]
In step S202, a request start notification is received from the uploader UL, and the server SV is stored in a state in which the request start notification has been received. Specifically, the server SV updates the update status table stored in the HDD 14.

  Referring to Table 4, when the status value in the update status table is “0”, the server SV has not received a request start notification from the uploader UL. When the status value is “1”, the server SV has received a request start notification from the uploader UL, but the database DB has not yet been updated. When the status value is “2”, the server SV receives a request start notification and the database DB is updated.

  Referring to FIG. 8, when receiving a request start notification from uploader UL, server SV determines whether or not the status value in the update status table is “0” (S2021). If the status value is “0”, the status value is changed to “1” (S2022). As a result, the server SV can determine that it has received a request start notification. If the update status is other than “0” as a result of the determination in step S2021, the server SV does not change the status value and ends the start notification receiving process.

[Update request processing and update processing]
Referring to FIG. 9, the uploader transmits an update request to request registration of song data M1n to server SV (S2031). At this time, the uploader UL adds the music information I1n of the music data M1n to the update request and transmits it.

  The server SV receives the update request (S2041), and registers a new song ID in the database DB to store the song data M1n (S2042). The server SV transmits the new song ID to the uploader UL (S2043). The uploader UL receives the new song ID (S2032), and transmits the received song data M1n to which the new song ID is assigned to the server SV (S2033). The server SV receives the music data M1n, and registers the music data M1n in the area of the new music ID in the database DB (S2044).

  After registering the song data M1n, the server SV updates the song list ML of all the song data M1 to Mn (S2045). Specifically, the server SV registers the song information I1n of the song data M1n in the song list ML.

  After updating the song list ML, the server SV updates the update status table (S2046 to S2049). First, the server SV determines whether or not the status value in the update status table is “0” (S2046). If the status value is not “0” as a result of the determination, the server SV determines whether the status value is “1” (S2048). In the present embodiment, since the server SV receives a request start notification from the uploader UL (step S202), the status value is normally “1”. If the status value is “1”, the server SV changes the status value to “2” (S2049). That is, the server SV stores that it has received a request start notification and has also registered the song data M1n.

  When the server SV registers the music data M11 to M1n after the second music, the status value in the update status table is already “2”. Therefore, since the status value is “2” as a result of the determination in step S2048, the server SV ends the update process as it is without changing the status value.

[Completion notification processing]
After the plurality of song data M10 to M1n are registered in the database DB of the server SV in step S20, the server SV transmits an update notification to the audio client CL and the uploader UL (S206). Referring to FIG. 10, the server SV determines whether or not the status value in the update status table is “2” (S2061). If the status value is “2” as a result of the determination, the server SV transmits an update notification to the audio client CL and the uploader UL (S2062). After transmitting the update notification, the server SV returns the status value to “0” (S2064), and ends the completion notification processing.

  On the other hand, if the status value is not “2” as a result of the determination in step S2061, the server SV further determines whether the status value is “1” (S2063). As a result of the determination, if the status value is “1”, the request start notification is received from the uploader UL, but the song data M1n is not registered. Therefore, in this case, the update notification is not transmitted and the status value is returned to “0” (S2064). If the update status is not “1” as a result of the determination in step S2063, the update status value is “0”, and thus the server SV ends the completion notification process.

  With the above operation, the server SV transmits an update notification after receiving a request completion notification from the uploader UL, that is, after registering a plurality of song data M10 to M1n. Therefore, the communication volume between the server SV and the audio client CL can be reduced as compared with the conventional network AV system that transmits the update notification every time the music piece data M1n is registered.

  Furthermore, the server SV can confirm its own state in the update status table. Specifically, it can be determined from the update status table whether the server SV has received a request start notification and whether the database DB has been updated. As a result, when the request start notification is received but the database DB is not updated, the update notification is not transmitted even if the request completion notification is received. Thereby, it is possible to prevent unnecessary communication from occurring.

2.1.3. Reproduction Operation Referring to FIG. 11, the audio client CL that has received the update notification from the server SV (S207) requests the play list PL from the server SV (S210). The playlist PL is a list of one or more pieces of music information In selected by the user of the audio client CL with the list construction key from the music information I1 to In of the music list ML registered in the server SV. is there. For example, when the user of the audio client CL wants to reproduce the music of artist P, the audio client CL transmits a list request command shown in Table 5 in step S210.

  The list request command includes a list construction key filter type and a keyword. The server SV receives a list request command from the audio client CL (S211), and creates a playlist PL based on the list construction key. Specifically, the server SV selects the song information In of the artist name “P” from the song list ML, and creates a playlist PL based on the selected one or more pieces of song information In. The created playlist PL is transmitted to the audio client CL (S212). The received list construction key is registered in the client information CLI in the server SV.

  The audio client CL receives the playlist PL (S213), and executes a song reproduction process for reproducing the song data Mn based on the playlist PL (S300). At this time, the server SV executes a music distribution process for distributing the music data Mn to the audio client CL in response to a request from the audio client CL (S310). Hereinafter, the music reproduction process and the music distribution process will be described in detail.

Referring to FIG. 12, the audio client transmits a song data transfer request command shown in Table 6 through the command port (S301).

  This song data transfer request command includes the acquisition start address and the acquisition data length of the song data Mn to be transferred. The song data Mn is requested to be transferred in the order of the playlist PL, for example.

  In response to the song data Mn transfer request command, the server SV distributes the song data Mn to the audio client CL from the start address specified by the acquisition start address by the length of the obtained data (S311). The audio client CL stores the distributed music data Mn in the memory 32. The memory 32 includes a plurality of buffers. The audio client CL acquires and stores music data for one buffer (= acquired data length) from the head of the music by a music data transfer request command (S302). After the storage, the audio client CL determines whether all the buffers in the memory 32 are filled with music data (S303), and acquires and stores music data until all the buffers are filled.

  Steps S301 to S303 are repeated, and when the buffer is completely filled with music data, the audio client CL starts reproduction (S304). Specifically, the music data starts to be output from the head buffer in the memory 32 to the audio processing unit 34. When music data is output and played back, there will eventually be an empty space for one buffer. When the memory 32 becomes empty (S305), the audio client CL transmits a music data transfer request to the server SV again (S306), and the server SV distributes the music data for the request (S312). The audio client CL stores the distributed music piece data in an empty buffer in the memory 32 (S307). After the storage, the audio client CL confirms whether or not all the music piece data Mn has been received (S308). When all the song data Mn has not been received, that is, when the server SV has not yet sent all the data of the song data Mn to the audio client CL, the audio client CL and the server SV are freed up in the memory 32 due to reproduction. Steps S306, S312, and S307 are repeated. In the above description, the reproduction is started after the buffer is completely filled with music data. However, the reproduction may be started before the buffer is completely filled.

  When the audio client CL receives all the song data Mn from the server SV (S308), the audio client CL continues the reproduction operation until all the song data Mn is reproduced (S309). When the reproduction of the music data Mn is completed, the audio client CL transmits a transfer request for the next music data Mn to the server SV based on the playlist PL.

2.2. When Uploader Registers Only One Song Data with Server Referring to FIG. 7 again, when uploader UL registers only song data M10 with server SV, the update request process (S203) at step S20 is performed only once. Execute. At this time, the uploader UL does not transmit the request start notification in step S201. That is, the uploader UL starts from the operation of step S203. Therefore, the server SV does not perform the start notification reception process in step S202, and the status value in the update status table remains “0”. The server SV update process (S204) at this time will be described.

  Referring to FIG. 9, the operation (S2041 to S2045) from when server SV receives an update request from uploader UL to update song list ML is the same as in 2.1.2. This is the same as the case (when a plurality of song data M10 to M1n are registered in the server SV).

  After updating the music list ML, the server SV determines whether or not the status value in the update status table is “0” (S2046). At this time, since the status value is “0”, the server SV transmits an update notification to the client CL (S2047). That is, when the uploader UL requests registration of the song data M1n for only one song, the server SV transmits an update notification if the song data M1n is registered without receiving the request completion notification. At this time, the uploader UL does not transmit a request completion notification (S205).

  Even when registering only one piece of music data M1n, if the uploader UL transmits a request start notification or a request completion notification, the traffic on the LAN 10 will increase. Therefore, in the network SV system according to the present embodiment, when registering only one song data M1n, the server SV can send the update notification without the uploader UL sending the request start notification or the request completion notification. By doing so, an increase in communication volume is prevented.

  Note that the server SV according to the present embodiment can also support a conventional uploader. That is, the conventional uploader does not transmit a request start notification or a request completion notification to the server SV. Therefore, when the server SV receives a registration request for a plurality of song data M10 to M1n from a conventional uploader, the server SV transmits an update notification every time one song is registered.

  In the network AV system 1 according to the present embodiment, the case where the song data M1n is registered has been described. However, when the song information In of the song data Mn is changed, the same operation is performed when the song data Mn is deleted. In the operation for deleting the song data Mn, it is sufficient to specify the song data Mn to be deleted. Therefore, the uploader UL does not send the song data Mn itself in the update request process (S203). Also, in the case of changing the song information In of the song data Mn, the uploader UL does not send the song data Mn itself, but sends the request start notification (S201) with the song information In to be changed attached. .

  In this embodiment, the content is music data, but the same applies to video data.

  While the embodiments of the present invention have been described above, the above-described embodiments are merely examples for carrying out the present invention. Therefore, the present invention is not limited to the above-described embodiment, and can be implemented by appropriately modifying the above-described embodiment without departing from the spirit thereof.

It is a functional block diagram which shows the structure of the network AV system by embodiment of this invention. It is a functional block diagram which shows the structure of the server in FIG. It is a functional block diagram which shows the structure of the audio client CL in FIG. It is a functional block diagram which shows the structure of the uploader in FIG. It is the schematic for demonstrating operation | movement of the network AV system of FIG. It is a flowchart which shows the connection operation | movement to the server of the uploader in FIG. It is a flowchart which shows the music data update operation | movement of the network AV system in FIG. It is a flowchart which shows the detail of operation | movement of step S202 in FIG. It is a flowchart which shows the detail of operation | movement of S210 in FIG. It is a flowchart which shows the detail of operation | movement of step S206 in FIG. It is a flowchart which shows the reproduction | regeneration operation | movement of the network AV system in FIG. It is a flowchart which shows the detail of operation | movement of step S300 and S310 in FIG.

Explanation of symbols

1 Network AV system 10 LAN
14 HDD
16 Database management unit 20, 40 CPU processing unit 22, 38, 43 LAN controller 28 Microcomputer processing unit 41 Request creation unit CL Audio client ML Song list Mn Song data PL Playlist UL uploader

Claims (9)

A server having a database in which a plurality of contents are stored;
An uploader connected to the server via a network and causing the server to update the database;
A client connected to the server via a network, receiving a content selected from the plurality of contents from the server, and playing the selected content;
The uploader is
Update request means for transmitting to the server one or more update requests for causing the server to update the database;
A completion notification means for transmitting a request completion notification to the server after the update request means has transmitted the one or more update requests;
The server
Updating means for updating the database in response to the one or more update requests;
An network AV system comprising: an update notification means for transmitting an update notification to the client that the database has been updated after receiving the request completion notification. The network AV system according to claim 1,
The client
When receiving the update notification, an acquisition means for acquiring information on the selected content from the server;
A network AV system comprising: request means for requesting the selected content from the server based on the information. The network AV system according to claim 1 or 2, wherein
The uploader further includes
Before the update request means transmits the plurality of update requests, comprising a start notification means for transmitting a request start notification to the server;
When receiving the request start notification, the update notification means transmits the update notification after receiving the request completion notification, and when receiving the update request without receiving the request start notification, the update means A network AV system, wherein the update notification is transmitted after updating the database in response to the update request. The network AV system according to any one of claims 1 to 3,
The server further includes:
A determination means for determining whether or not the database has been updated;
The network AV system, wherein the update notification unit transmits the update notification when the determination unit determines that the database has been updated.   A network AV program for causing a computer to execute the means according to any one of claims 1 to 4. A server having a database in which a plurality of contents are stored, an uploader connected to the server via the network and updating the database to the server, and connected to the server via the network and selected from the plurality of contents A server in a network AV system comprising: a client that receives received content from the server and reproduces the selected content;
Updating means for updating the database in response to an update request for the database transmitted from the uploader;
An update notification means for sending an update notification to the client that the database has been updated after receiving a request completion notification to complete the update request from the uploader. The server according to claim 6, wherein
When the update notification means receives a request start notification to start an update request from the uploader, it transmits the update notification after receiving the request completion notification, and the update request without receiving the request start notification When the server receives the update, the update unit transmits the update notification after updating the database in response to the update request. An uploader in a network AV system, comprising: a server having a database in which a plurality of contents are stored; and an uploader connected to the server via a network and updating the database.
Update request means for transmitting to the server one or more update requests for causing the server to update the database;
An uploader, comprising: a completion notification unit that transmits a request completion notification to the server after the update request unit transmits the one or more update requests. The uploader according to claim 8, further comprising:
An uploader, comprising: a start notification unit that transmits a request start notification to the server before the update request unit transmits the plurality of update requests.

Images