Method and device for restoring a target file of an operating software and device for using the same

Description

TECHNICAL FIELD OF THE INVENTION

[0001] The subject of the invention is a method for recovering a target file as well as the devices for using such a method.

[0002] The field of the invention is that of audio / video reception equipment and more particularly that of updating such equipment.

[0003] A target file is, for example, an operating software for audio / video equipment or a video file. STATE OF PRIOR ART

[0004] Audio-video reception equipment is a processing device capable of receiving signals, whether analog or digital, and of formatting these signals so that they can be viewed on a screen, for example a television. Typically, such equipment includes: Terrestrial radio, satellite radio and / or cable input interfaces; and At least one output interface, for example an HDMI, Display Port, SCART or other interface.

[0005] Such equipment is generally called a "box" or a "set top box." It is the basic equipment provided by television operators.

[0006] Traditionally, audio-video reception equipment also allows you to browse the Internet, access replay services and access other services.

[0007] Audio-video receiving equipment is usually controlled by a remote control. This can be a traditional remote control or a mobile phone connected directly to the equipment or to the same local network as the equipment.

[0008] Such equipment can be integrated into a TV.

[0009] Such equipment includes an operating system to manage the interaction of its features with commands issued by a user. This operating system is also called "firmware." It is common to be able to update the firmware to allow the equipment to adapt to changing features.

[0010] The solution of the state of the art consists of broadcasting, on a dedicated channel via data packets, packets corresponding to the instruction codes of the operating system. These packets are broadcast continuously, one after the other in a cyclical manner. That is to say, after the broadcast of the last packet, the broadcast resumes with the first packet. Thus, it is sufficient for the equipment to listen to the dedicated channel to retrieve all the data packets whose assembly will allow it to update its operating system. Conventionally, a data packet includes an identifier which is composed of a version number and a sequence number in the version. The ordered assembly of all the packets of a version makes it possible to reconstruct the file corresponding to the operating system.

[0011] This system has the disadvantage of being long. Indeed, the order of magnitude of the size of an operating system for audio / video reception equipment is 130 MB. On a satellite reception interface, knowing that the update channel has a narrow bandwidth for reasons of profitability, this can represent a recovery time of the order of 17 minutes with a flow rate of 1 Mbps, which is not the norm. In the case of new equipment delivered without an operating system, or with a minimal operating system, this time can be perceived as very disappointing. STATEMENT OF THE INVENTION

[0012] The invention solves this problem of updating the operating system of an audio / video receiving device by teaching the use of several distinct broadcast interfaces, at least one of which has no return path. This is also referred to as an unconnected broadcast interface. The invention generally makes it possible to optimize the retrieval of a target file, which may also be a video file that must be pushed to an audio / video receiving device, the video file having to be pushed, for example, following a transaction on a video-on-demand platform.

[0013] The general principle of the invention is to make the data available simultaneously: In the "normal" direction, from start to finish, on an IP interface via a file server (HTTP / FTP / ...); In the "reverse" direction, from end to start, on a broadcast interface via a DSM-CC carousel, we will speak of a dedicated channel.

[0014] Thus the audio / video reception equipment acquires data simultaneously on both interfaces: The audio / video receiving equipment connects to the DSM-CC carousel and starts receiving data from a Pn packet (which is the packet present on the carousel at the moment the STB connects), The carousel broadcasts the data in reverse order, the audio / video receiving equipment receives the Pn, Pn-1, Pn-2... packets from the carousel, At the same time, the audio / video receiving equipment connects to a server through the IP network and requests the packets in normal order starting with the Pn+1 packet then Pn+2, etc. When one of the interfaces reaches one end of the file, it loops back and continues from the other end: when the carousel reaches the first P0 packet, it continues from the last PN packet (normal operation for a carousel), and when the IP download reaches the last PN packet, it continues from the first P0 packet.

[0015] The download is complete when all data from the target file has been acquired.

[0016] The subject of the invention is therefore a method for recovering a target file by audio / video reception equipment, said audio / video reception equipment comprising at least two communications interfaces, a first communications interface capable of receiving broadcast data and a second communications interface capable of establishing a two-way dialogue with a server, characterized in that the method comprises the following steps: Connecting the first communication interface to a predetermined channel broadcasting target data, the data being structured into packets, each packet being of one type among predefined types; Receiving, via the first communication interface, a description packet comprising information on the structure of the data packets making up the target file; Allocating a storage area of ​​a size determined according to the description, each packet being associated with a size, the size of the storage area being equal to the sum of the sizes of the packets; Receiving via the first interface a first data packet, each data packet comprising: ∘ A packet rank identifier representing the rank of the packet among all the packets of the target file; ∘ Data in quantity as described by the description packet received;Sending a first request via the second communication interface to obtain the target file from a request position determined from the position in the target file of the first packet received; Recording the data received by the first interface in the allocated storage area; Recording the data received by the second interface in the allocated storage area; Stopping the recordings when the allocated storage area is full; the data packets received via the first interface being received in descending order, while the packets received via the second interface being received in ascending order, when recording the data received by the first interface in the allocated storage area, the data being recorded from the first packet received towards the beginning of the target file, each data packet being recorded from a position equal to the sum of the sizes of the packets of lower rank than its own in the storage area and, when recording the data received by the second interface in the allocated storage area, the received bytes being continuously recorded from the position used by the first request in the storage area, the data being recorded from the end of the first packet received towards the end of the target file.

[0017] In addition to the main characteristics which have just been mentioned in the preceding paragraph, the method / device according to the invention may have one or more additional characteristics among the following, considered individually or according to the technically possible combinations: The packet structure information comprises at least a number of data packets to reconstruct the target file and at least one size Tp of a data packet associated with at least one packet rank; The packet structure information comprises the number of data packets to reconstruct the target file, the size of a packet being known a priori and all the packets having the same size; The packet structure information comprises the size of a packet and the size of the target file; The data are received in different orders on the two interfaces; If the value obtained by adding the position used by the first request with the quantity of data obtained in response to the first request becomes greater than or equal to the size of the allocated storage area then the method comprises the following steps: ∘ End of the recording of the data received by the second interface in response to the first request;∘ Issuing a second request via the second communication interface to obtain the target file from a request position equal to 0; ∘ Saving the data received by the second interface, in response to the second request, in the allocated storage area, the received bytes being continuously saved from the position used by the second request in the storage area;If the current write position, in the storage area, of the data received via the second interface has been lower than the current write position, in the storage area, of the data received via the first interface, and if the current write position, in the storage area, of the data received via the second interface becomes higher than the current write position, in the storage area, of the data received via the first interface, then the method implements the following steps: ∘ Ending the recording of the data received by the second interface; ∘ Sending a third request via the second communication interface to obtain the target file from a request position equal to the position of a first missing packet;∘ Recording the data received by the second interface, in response to the third request, in the allocated storage area, the received bytes being continuously recorded from the position used by the third request in the storage area up to the size of the packet; ∘ Repetition of the previous steps as long as there are missing packets; The data of a data packet received via the first interface are recorded in the storage area only if the identifier of the data packet is associated, at the receiving equipment, with information on the absence of data. ;

[0018] The invention also relates to a non-transitory memory device comprising instruction codes for implementing the method according to one of the possible combinations of the preceding characteristics.

[0019] The invention also relates to audio / video reception equipment implementing a method according to one of the possible combinations of the preceding characteristics.

[0020] The invention also relates to a computer program product comprising instructions which, when the program is executed by a computer, cause the latter to implement the steps of the method according to one of the possible combinations of the preceding characteristics. BRIEF DESCRIPTION OF THE FIGURES

[0021] Other characteristics and advantages of the invention will emerge from reading the description which follows, with reference to the appended figures, which illustrate: There figure 1 : an illustration of audio / video reception equipment capable of implementing the method according to the invention; The figure 2 : an illustration of steps of the method according to the invention.

[0022] For clarity, identical or similar elements are identified by identical reference signs throughout the figures.

[0023] The invention will be better understood by reading the following description and examining the accompanying figures. These are presented for information purposes only and in no way limit the invention. DETAILED DESCRIPTION OF AN EMBODIMENT

[0024] There figure 1 shows a 100 audio / video reception equipment. The figure 1 shows that the equipment 100 includes: A microprocessor 110; Storage means 120. Storage means are, for example: a hard disk, a solid-state disk, a memory component such as a flash memory; An interface 130 for communication with a remote control 200, for example an infrared communication interface or a radio communication interface; An interface 140 for communication with a screen not shown, for example a SCART, HDMI, Miracast, DVI, VGA, etc. communication interface; A first interface 150 for receiving a multimedia broadcast. Such an interface is, for example, an interface to the digital terrestrial television broadcasting network, or an interface to a satellite broadcasting network. This first interface has no return path. It is therefore a unidirectional communication interface; A second communication interface 160 capable of establishing connections through a network 300, for example the Internet network.

[0025] There figure 1 shows that the microprocessor 110 of the audio / video reception equipment 100, the storage means 120 of the audio / video reception equipment 100, the interface 130 for communication with the remote control of the audio / video reception equipment 100, the interface 140 for communication with the screen of the audio / video reception equipment 100, the first reception interface 150 of the audio / video reception equipment 100 and the second communication interface 160 of the audio / video reception equipment 100 are interconnected by a bus 170.

[0026] In this description, when an action is attributed to a device, this action is in fact carried out by a microprocessor of said device controlled by instruction codes recorded in a memory of said device. In the same way, if an action is attributed to a program, or to an application, this action is the result of the implementation of instruction codes by a microprocessor of a device in which the program or application is installed.

[0027] There figure 1 shows that the storage means 120 of the audio / video reception equipment comprise several zones: An operating system area 120.1; An update management area 120.2 comprising instruction codes which, when the corresponding program is executed by the equipment, cause the latter to implement the steps of the method according to the invention. The area 120.2 may be included in the operating system area 120.1. The area 120.2 may also correspond to a specific memory of the startup program type; A configuration area 120.3 which comprises: o An identifier of a target data packet reception channel, this identifier being, from the point of view of the invention, predetermined and entered in the factory or by manual configuration; ∘ An identifier of a file distribution server, this address being, from the point of view of the invention, predetermined and entered in the factory or by manual configuration; A data packet database area 120.4 for tracking the progress of an update; An area 120.5 storing a target file to save a target operating system file before the update replaces the current version in the 120.1 operating system area.

[0028] There figure 1 shows that the data packet database area 120.4 is structured to allow all or part of the following information to be associated with a packet identifier 120.4.1, according to the embodiments: Packet size; Packet reception status. This status depends on whether the packet was successfully received and saved in the update storage area or not.

[0029] A case where packet size is optional is the case where all packets have the same size. An equivalent case is the case where all packets have the same size except one, the last one.

[0030] There figure 1 shows a 400 file distribution server. The figure 1 shows that server 400 has: A microprocessor 410; Storage means 420; A communication interface 460 capable of establishing connections through the network 300.

[0031] There figure 1 shows that the microprocessor 410 of the distribution server, the storage means 420 of the distribution server and the communication interface 460 of the distribution server are interconnected by a bus 470.

[0032] There figure 1 shows that the storage means 420 of the distribution server comprises an area 420.1 in which target files are recorded, each target file being identified at least by its version. In one variant the files are also identified by a model, that is to say by an identifier of the audio / video reception equipment for which they are adapted. In yet another variant the version number is linked to the model, that is to say that knowing the version number, the model is implicit.

[0033] Server 400 is a server compatible with at least the http protocol.

[0034] There figure 2 shows an initial step 1000 in which the audio / video reception equipment 100 must manage a request to retrieve a target file. In our example, the target file is an update of the equipment's operating software. This request may arise from internal planning, a reset of the equipment, or the activation of a menu by the equipment's user. These are just examples of possible request origins.

[0035] Following this request, the audio / video reception equipment moves to a step 1010 of connecting the first communication interface to the channel whose identifier is recorded in the configuration zone of the storage means of the audio / video reception equipment. On this channel, the equipment receives at least two types of packets: Description packets; Data packets.

[0036] Each received packet is structured to allow its type and content to be read. From the moment the first interface is connected, the audio / video receiving equipment receives and processes all broadcast packets.

[0037] In a step 1020 of receiving a description packet, following the connection step 1010, the audio / video reception equipment receives a description packet. This is the first description packet broadcast since the connection step. In a variant, this description packet is structured to contain at least: The number of packets needed to reconstruct a file corresponding to the operating system. In our example, we consider that Mp data packets are needed to reconstruct an operating system update file; for each of the data packets used for reconstruction, the size of the data contained in the packet.

[0038] In practice, the description packet also includes data relating to a version number of the described file. This allows the audio / video receiving equipment to determine whether the description packet is compatible with itself. The equipment only selects for an update those description packets that are compatible with itself. This selection is made, for example, via a model identifier contained in the description packet. This model identifier of the description packet must correspond to a model identifier recorded in the configuration area. In a variant, this model identifier is part of a version identifier. For the remainder of the description, this version identifier is implicitly used to select the data packets retained from among the data packets received via the first interface.

[0039] In practice, there are several variants for describing a target file in a description file. For example, we consider that the description package includes: The size of the target file, and The size of each packet. This can be one and only one size, with each data packet having the same size, or a list of sizes, with each size in the list associated with a data packet ID.

[0040] In one variant, the header of a data packet includes a size identifier, where this identifier refers to a size in a list of sizes. This size list is either known a priori or transmitted via the description packet.

[0041] In yet another variant, the size of a data packet is known a priori and each data packet has the same size. It is then sufficient for the description packet to contain the size of the target file so that the number of data packets can be deduced by simply dividing the size of the target file by the known size of a data packet.

[0042] The common point of all these variants is that between the data transmitted by the description packet and the data known a priori it is possible, by simple arithmetic, to calculate the position of a data packet in the target file.

[0043] There is also a variant in which the description file contains only the size of the target file and no other data is known a priori. In this variant, it is the header of a data packet that contains the position of the data packet in the target file. In this variant, the header of the data packet also contains the size of the data packet.

[0044] It is recalled that the size of a data packet is, in this document, the size of the data contained in this data packet.

[0045] Once the description of the target file is known, the principle is therefore that the equipment selects, from the description packets received, the first description packet that corresponds to it. This correspondence relates to the model of the equipment and to the version of the update. The equipment may possibly filter the version of the update and choose to retrieve only a version later than the operating system version already installed. A variant could be to accept all versions in the case of an emergency restoration of the equipment following, for example, corruption of the operating system of the equipment or a forced update request. At the end of step 1020 of receiving a description packet, the equipment is therefore capable of selecting data packets from those received via the first interface.This behavior being comparable to that of the state of the art, for the rest of the description we consider this selection as implicit and we are only interested in the packet identifier, that is to say its rank in the set of packets forming the update.

[0046] The audio / video reception equipment then moves on to a step 1030 of allocating a storage area. This storage area is managed by a database. This is the database previously described in relation to the database area of ​​the storage means of the audio / video reception equipment.

[0047] In the allocation step 1030 the audio / video reception equipment uses the data obtained to calculate the size of the storage area 120.5 of an update file. This size is obtained by summing the size of each of the packets described by the description packet previously received. If all the packets have the same size, the size of the storage area is the result of the product of the number of packets by the size of a packet. This case is considered for the remainder of the description, each data packet has a size Tp, that is to say it contains Tp bytes of data. In this case the size of the storage area of ​​the update file is equal to Mp x Tp in bytes.

[0048] At allocation step 1030, the audio / video receiving equipment also initializes the packet database by associating the status “not received” or “KO” with each packet identifier. In our example, the data packets are identified by their rank from 1 to Mp. In another example, the rank, and therefore the identifier, of the packet may be its position, expressed in bytes, in the update file. In other words, it would be an offset in bytes from the start of the update file to the position of the start of the packet.

[0049] The audio / video receiving equipment then moves on to a step 1040 of receiving via the first interface a first data packet P1. The first data packet, like all data packets, is structured to include at least the following data: A 501 packet type. Possible types are at least “description” and “data”; A 502 packet identifier. In our case, an integer between 1 and Mp; A 503 payload area containing Tp bytes of data.

[0050] In this step of receiving the first data packet, the audio / video equipment performs the following actions: It saves the packet data at the desired position in the update file storage area. The desired position, with the parameters in the example, is equal to: (packet rank - 1) x packet size It updates the packet database for the packet identifier. To perform this update it modifies the status of the packet according to the result of the save operation: The status is "OK" if the save was successful, otherwise the status is "KO"; It memorizes the rank of the first data packet saved.

[0051] Then the audio / video receiving equipment launches two processes that run in parallel: A first process 1050 for recording data packets received via the first interface; A second process 1100 for retrieving data from the update file from the distribution server 400.

[0052] The first process entry point 1050 is a step 1060 of waiting for a data packet to be received via the first interface. If a data packet is received via the first interface, then we proceed to a step 1060 of recording the data packet. Otherwise, we continue to wait.

[0053] In step 1070 of recording the data packet the audio / video receiving equipment performs the following actions: It checks the status of the package in the database, and if this status is "KO" then: ∘ It saves the package data at the desired position in the update file storage area. ∘ It updates the package database for the package identifier.

[0054] The audio / video receiving equipment then moves to a step 1080 in which it checks whether the update file has been completely received. This check is done by ensuring that, in the packet database, all the packets have a status of "OK". If this is the case, then we move to a step 2000 for finalizing the reception of the update file, otherwise we move to step 1060 for waiting for reception of a packet.

[0055] In the invention, on the update channel, the data packets are broadcast in descending order of rank. That is, the data packet that will be broadcast after the packet of rank N will be the data packet of rank N-1. The update file is, in a way, broadcast in reverse.

[0056] The entry point of the second process 1100 is a step 1110 of sending a first request, via the second interface, to the distribution server. This request is a request according to the http or https protocol. The parameters of this request are: An identifier of the file to be downloaded, this identifier being obtained via the description packet and / or the model of the audio / video receiving equipment; A download start position, this position being equal to the sum of the sizes of the packets of rank less than or equal to the rank of the first packet received. In our example this position is equal to the size of a packet multiplied by the rank of the first packet received. This corresponds to the position in the target file of the first packet received, position to which we add the size of the first packet received. This position is therefore calculated according to the position in the target file of the first packet received. The calculation method depends on the description mode used by the description packet.

[0057] The audio / video receiving equipment then proceeds to a step 1120 in which it receives, in response to the first request, data via the second interface. This data is data from the update file corresponding to the packets of ranks higher than the rank of the first data packet received. The audio / video receiving equipment.

[0058] In step 1120 of receiving data via the second interface, the audio / video receiving equipment records the data received via the second interface in the storage area of ​​the update file from a position equal to the download start position of the request whose response is received. The identifier of the packet whose status is to be updated is deduced from: The starting position of the request; The total amount of data received in response to the request.

[0059] There figure 3 illustrates the fact that: The first process records data from the first packet received to the beginning of the update file; The second process records data from the end of the first packet received to the end of the update file.

[0060] In step 1120 of receiving data in response to the first request, the audio / video receiving equipment updates the packet database as it receives data. Each time Tp bytes are received, the audio / video receiving equipment updates the status of the corresponding packet in the packet database. This is a sub-step 1130 of step 1130 of updating the packet database.

[0061] The sub-step 1130 of updating the packet database is followed by a sub-step 1140 of checking that the end of the file has been reached.

[0062] If the end of the file is reached, then we move on to a step 1141 of sending a second request via the second communication interface to obtain the update file from a request position equal to 0. It is understood that the processing corresponding to the previously active request is interrupted. The processing then continues at step 1120 of receiving data via the second interface.

[0063] If the end of the file is not reached, then we proceed to a step 1150 to verify a crossover between the first process and the second process. This step is optional. If this step is not implemented, then we proceed to a step 1180 to verify whether the update file is complete or not.

[0064] A crossover has occurred if the current write position, in the storage area, of the data received via the second interface has been lower than the current write position, in the storage area, of the data received via the first interface, and if the current write position, in the storage area, of the data received via the second interface becomes higher than the current write position, in the storage area, of the data received via the first interface. It is recalled that the first process records packets towards the beginning of the update file, while the second process records packets towards the end of the update file.

[0065] If a crossover has occurred, a step 1151 is moved to search for a missing packet in the packet database. For this search, the audio / video receiving equipment scans the packet database in ascending order of rank to find a packet whose status is "KO". Such a packet, found after a crossover, is a missing packet, i.e. a packet that was poorly, or not, received via the first interface. The scan begins from the last packet received via the second interface.

[0066] If a packet is missing, then we proceed to a step 1152 of sending a third request via the second communication interface to obtain the update file from a request position equal to the position of the missing packet in the update file storage area. It is understood that the processing corresponding to the previously active request is interrupted. The processing then continues at step 1120 of receiving data via the second interface.

[0067] If no packets are missing, we proceed to step 1180 in which the audio / video receiving equipment checks whether the update file has been completely received. This step is identical to step 1080 of the same name for the first process. If the update file is complete, then we proceed to step 2000 for finalizing the reception of the update file, otherwise we proceed to step 1120 for receiving data via the second interface.

[0068] In step 2000 of finalizing the reception of the update file, the audio / video receiving equipment uses the contents of the update file storage area 120.5 to update the operating system area 120.1.

[0069] With the invention it is therefore possible to significantly speed up the recovery of an update file for an operating system of audio / video reception equipment. The external impacts on the equipment are minor: No impact at the distribution server level 400, we use the standard capabilities of the http protocol; At the level of packet distribution via the unidirectional broadcast interface, we reverse the order of distribution of the data packets.

[0070] The invention is particularly effective when the two data retrieval processes write in opposite directions. In other words, the data is received in different order on the two interfaces. In the described implementation example, the first process writes received data in descending order to the beginning of the file, while the second process writes received data in ascending order to the end of the file. This is the most elegant case because it involves few changes to both the equipment and the infrastructure.

[0071] The principle of the invention still applies if data packets are received on the first interface in ascending order. In this case, the data must be received on the second interface in reverse order, i.e. descending, and written towards the beginning of the file. Such a result can be obtained, for example, by saving the files in reverse on the distribution server or by reading them from the end to the beginning.

[0072] The invention also works perfectly for recovering any type of file, for example video files.

Claims

1. A method for recovering a target file by an audio / video receiving equipment (100), said audio / video receiving equipment including at least two communication interfaces, a first communication interface (150) able to receive broadcast data and a second communication interface (160) able to establish a bidirectional dialog with a server (400), characterised in that the method includes the following steps of: - connecting (1010) the first communication interface on a predetermined channel broadcasting target data, the data being structured as packets, each packet being of a type among predefined types; - receiving (1020), via the first communication interface a description packet including information about the structure of the data packets making up the target file; - allocating (1030) a storage zone of a determined size according to the description, each packet being associated with a size, the size of the storage zone being equal to the sum of the packet sizes; - receiving (1040) via the first interface a first data packet, each data packet including: ∘ a packet rank identifier representing the rank of the packet among all the packets of the target file; ∘ data in an amount such as described by the description packet received; - transmitting (1110) a first request via the second communication interface to obtain the target file from a determined request position from the position in the target file of the first packet received; - recording (1050) the data received by the first interface in the allocated storage zone, - recording (1120) data received by the second interface in the allocated storage zone; - stopping (2000) recordings when the allocated storage zone is full, the method being characterized in that the data packets received via the first interface are received in decreasing rank, while the packets received via the second interface are received in ascending rank, in that, when recording (1050) the data received by the first interface in the allocated storage zone, the data is recorded from the first packet received towards the beginning of the target file, each data packet being recorded from a position equal to the sum of the sizes of the packets of lower rank than its own in the storage zone and in that, when recording (1120) the data received by the second interface in the allocated storage zone, the received bytes are continuously recorded from the position used by the first request in the storage zone, the data being recorded from the end of the first packet received towards the end of the target file.

2. The method for recovering a target file according to claim 1, characterised in that the information about the packet structure includes at least one number of data packets to reconstitute the target file and at least one size Tp of a data packet associated with at least one packet rank.

3. The method for recovering a target file according to claim 1, characterised in that the information about the packet structure includes the number of data packets to reconstitute the target file, the size of a packet being known a priori and all the packets having the same size.

4. The method for recovering a target file according to claim 1, characterised in that the information about the packet structure includes the size of a packet and the size of the target file.

5. The method for recovering a target file by an audio / video receiving equipment according to one of the preceding claims, characterised in that if the value obtained by adding the position used by the first request with the amount of data obtained in response to the first request becomes higher than or equal to the size of the allocated storage zone, then the method includes the following steps of: - ending recording the received data by the second interface in response to the first request; - transmitting (1141) a second request via the second communication interface to obtain the target file from a request position equal to 0; - recording (1120) the data received by the second interface, in response to the second request, in the allocated storage zone, the bytes received being continuously recorded from the beginning of the storage zone.

6. The method for recovering a target file by an audio / video receiving equipment according to one of the preceding claims, characterised in that< / b> if the current writing position, in the storage zone, of data received via the second interface has been lower than the current writing position, in the storage zone, of data received via the first interface, and if the current writing position, in the storage zone, of data received via the second interface becomes higher than the current writing position in the storage zone of data received via the first interface, then the method implements the following steps of: - ending recording the data received by the second interface; - transmitting (1152) a third request via the second communication interface to obtain the target file from a request position equal to the position of a first missing packet; - recording (1120) the data received by the second interface, in response to the third request, in the allocated storage zone, the bytes received being continuously recorded from the position used by the third request in the storage zone up to the size of the packet; - repeating (1151) the previous steps as long as there are missing packets.

7. The method for recovering a target file by an audio / video receiving equipment according to one of the preceding claims, characterised in that the data of a data packet received via the first interface are recorded (1070) in the storage zone only if the data packet identifier is associated, at the receiving equipment, with data absence information.

8. A non-transitory memory device including instruction codes for implementing the method according to one of the preceding claims.

9. An audio / video receiving equipment implementing a method according to one of claims 1 to 7.

10. A computer program product including instructions which, when the program is executed by a computer, cause the same to implement the steps of the method according to one of claims 1 to 7.