Live broadcast fault detection and processing method and its device, equipment, medium, and product

Abstract

The present application discloses a method for detecting and processing live broadcast faults and its apparatus, equipment, medium, and product, the method comprising: responding to a fault reporting event, detecting the fault type existing in the current live broadcast room of the client that triggered the event, and storing the fault information containing the fault type in the fault log; broadcasting the fault information in the fault log to the current live broadcast room, driving the current live broadcast room to output the fault information to the fault voting control, so as to obtain the fault voting information pushed by the client through the fault voting control; according to the fault voting information, determining the priority of the fault type contained in each fault information in the fault log, and selecting some fault types with higher priority to send corresponding notifications to the current live broadcast room. The application of the present application can provide fault feedback services to users in the live broadcast room, so as to determine the faults existing in the live broadcast room, and then perform fault notifications, and carry out targeted repairs based on the collected faults, so as to improve the operational stability of the live broadcast room.

Description

Technical Field

[0001] The present application relates to the technical field of network live broadcasting, and in particular to a method for detecting and processing live broadcasting faults, and also to corresponding devices, equipment, non-volatile storage media and computer program products of the method. Background Art

[0002] The live broadcast room online services provided by the existing live broadcast platforms have various types of live broadcast functions to meet the user experience of audience users or anchor users who use the live broadcast services. However, the rich live broadcast functions of the live broadcast services are often prone to corresponding failures, which result in users being unable to use the corresponding live broadcast functions to conduct live broadcast activities. However, when a live broadcast application run by a user fails, the user can generally only provide feedback by sending an email to the live broadcast platform to notify the live broadcast platform to repair the failure. The fault feedback process that is separated from the live broadcast service will often result in users being unable to provide immediate feedback, resulting in the failures in the live broadcast room often only being able to be tested by the platform's testers. This will make it impossible for the failures in the live broadcast room to be repaired in a timely manner, affecting the user's experience of using the live broadcast service.

[0003] In view of the above problems, the applicant has made corresponding explorations in order to solve the problems. Summary of the invention

[0004] The purpose of this application is to provide a live broadcast fault detection and processing method to meet user needs. In addition, it also relates to corresponding devices, equipment, non-volatile storage media and computer program products of the method.

[0005] In order to achieve the purpose of this application, the following technical solutions are adopted:

[0006] A live broadcast fault detection and processing method proposed for the purpose of this application includes the following steps:

[0007] In response to a fault reporting event, detecting the fault type existing in the current live broadcast room of the client that triggered the event, and storing fault information including the fault type in a fault log;

[0008] Broadcast the fault information in the fault log to the current live broadcast room, drive the current live broadcast room to output the fault information to the fault voting control, so as to obtain the fault voting information pushed by the client through the fault voting control;

[0009] According to the fault voting information, the priority of the fault type contained in each fault information in the fault log is determined, and some fault types with higher priority are selected to send corresponding notifications to the current live broadcast room.

[0010] In a further embodiment, before responding to the fault reporting event, the preceding steps are performed by the client in the current live studio:

[0011] In response to the fault message body editing event, the fault report text and the fault screenshot of the fault report control in the current live broadcast room are obtained, and the fault report control is used by the client to edit the fault report text and the fault screenshot;

[0012] Push a fault message body including the fault report text and the fault screenshot to the server to trigger the server to detect the fault type existing in the current live broadcast room according to the fault message body.

[0013] In a further embodiment, the step of responding to the fault reporting event and detecting the fault type existing in the current live broadcast room of the client that triggered the event includes the following steps:

[0014] Receive the fault message body pushed by the client in the current live broadcast room, and transmit the fault report text in the fault message body to the text semantic recognition model that has been trained to a convergence state;

[0015] Obtaining a semantic recognition result generated by the text semantic recognition model according to the fault report text, and determining a fault type represented by the semantic recognition result;

[0016] Generate fault information including the fault type and the fault screenshot in the fault message body, and store the fault information in the fault log.

[0017] In a further embodiment, the step of responding to the fault reporting event and detecting the fault type existing in the current live broadcast room of the client that triggered the event includes the following steps:

[0018] Monitor the live audio stream of the anchor client in the current live broadcast room, and transmit the live audio stream to the audio semantic recognition model that has been trained to a convergence state;

[0019] Obtaining an audio recognition result generated by the audio semantic recognition model according to the audio semantic fault reporting text output by the live audio stream, and determining a fault type represented by the audio recognition result;

[0020] Fault information including the fault type is generated, and the fault information is stored in the fault log.

[0021] In a further embodiment, the step of broadcasting the fault information in the fault log to the current live broadcast room, driving the current live broadcast room to output the fault information to the fault voting control, and obtaining the fault voting information pushed by the client through the fault voting control, includes the following steps performed by the client:

[0022] Obtain one or more fault information broadcasted by the server, so as to output the fault information to the fault voting control for display;

[0023] In response to a fault voting event acting on the fault voting control, generating the fault voting information including the fault type in the fault information pointed to by the event;

[0024] The fault voting information is pushed to the server so that the server determines the priority of the fault type according to the fault voting information.

[0025] In a further embodiment, the step of determining the priority of the fault type contained in each fault information in the fault log according to the fault voting information, and selecting some fault types with higher priority to send corresponding notifications to the current live broadcast room includes the following steps:

[0026] According to the fault types pointed to by the fault voting information pushed by each client, counting the number of votes for each of the fault types;

[0027] According to the vote counts of the fault types, determining the respective priorities of the fault types according to the vote counts;

[0028] Generate a fault notification of a higher priority fault type and push the fault notification to the target client of the current live broadcast room.

[0029] In a preferred embodiment, after the step of determining the priority of the fault type contained in each fault information in the fault log according to the fault voting information and selecting some fault types with higher priority to send corresponding notifications to the current live broadcast room, the method further comprises:

[0030] Pushing a fault repair patch for repairing the fault type corresponding to each fault information in the fault log to the client in the current live broadcast room, so as to repair the fault existing in the current live broadcast room;

[0031] Obtain the feedback information pushed by the client in the current live broadcast room, and store the feedback information in the repair log.

[0032] A live broadcast fault detection and processing device proposed for the purpose of this application includes:

[0033] A fault detection module is used to respond to a fault reporting event, detect the fault type of the client that triggers the event in the current live broadcast room, and store the fault information containing the fault type in the fault log;

[0034] A fault information broadcasting module is used to broadcast the fault information in the fault log to the current live broadcast room, drive the current live broadcast room to output the fault information to the fault voting control, and obtain the fault voting information pushed by the client through the fault voting control;

[0035] The priority determination module is used to determine the priority of the fault type contained in each fault information in the fault log according to the fault voting information, and select some fault types with higher priority to send corresponding notifications to the current live broadcast room.

[0036] In a further embodiment, the fault detection module includes:

[0037] A message body receiving submodule is used to receive the fault message body pushed by the client in the current live broadcast room, and transmit the fault report text in the fault message body to the text semantic recognition model that has been trained to a convergence state;

[0038] A semantic recognition result acquisition submodule, used to acquire a semantic recognition result generated by the text semantic recognition model according to the fault report text, and determine the fault type represented by the semantic recognition result;

[0039] The fault information storage submodule is used to generate fault information including the fault type and the fault screenshot in the fault message body, and store the fault information in the fault log.

[0040] In a preferred embodiment, the fault detection module further includes:

[0041] The audio stream monitoring submodule is used to monitor the live audio stream of the anchor client in the current live broadcast room, and transmit the live audio stream to the audio semantic recognition model that has been trained to a convergence state;

[0042] An audio recognition result acquisition submodule is used to obtain an audio recognition result generated by the audio semantic recognition model according to the audio semantic fault reporting text output by the live audio stream, and determine the fault type represented by the audio recognition result;

[0043] The fault information generation submodule is used to generate fault information containing the fault type and store the fault information in the fault log.

[0044] In a further embodiment, the priority determination module includes:

[0045] A voting number counting submodule, used for counting the number of votes for each fault type according to the fault types pointed to by the fault voting information pushed by each client;

[0046] A priority determination submodule, used to determine the respective priorities of the fault types according to the vote counts of the fault types;

[0047] The fault notification generation submodule is used to generate a fault notification of a fault type with a higher priority and push the fault notification to the target client of the current live broadcast room.

[0048] In order to solve the above technical problems, an embodiment of the present application also provides a computer device, including a memory and a processor, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor executes the steps of the above-mentioned live broadcast fault detection and processing method.

[0049] In order to solve the above technical problems, an embodiment of the present application also provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the above-mentioned live broadcast fault detection and processing method.

[0050] In order to solve the above technical problems, an embodiment of the present application also provides a computer program product, including a computer program and computer instructions. When the computer program and computer instructions are executed by a processor, the processor executes the steps of the above-mentioned live broadcast fault detection and processing method.

[0051] Compared with the prior art, the advantages of this application are as follows:

[0052] The present application provides a fault feedback service to users in the live broadcast room to detect faults existing in the live broadcast room, and broadcasts the collected fault feedback to the live broadcast room for fault consultation to determine whether these faults exist in most of the clients in the live broadcast room, and then prioritizes the fault type, predicts whether the fault type existing in the live broadcast room is a fault problem existing in the client's equipment or a fault problem existing in the business system of the live broadcast room, prevents waste of resources in repairing faults that do not exist in the live broadcast business system, and thus improves the efficiency of repairing faults existing in the live broadcast room, so as to notify the anchor of the live broadcast room of faults with higher priority in the live broadcast room, facilitate the anchor to adjust the live broadcast business, and improve the user experience of various types of users using the live broadcast service.

[0053] Secondly, the fault feedback service provided by this application is combined with the live broadcast business system, and users can quickly feedback the faults existing in the various live broadcast functions in the live broadcast service to the live broadcast platform, preventing the faults discovered by users from having nowhere to be reported, thereby improving the platform's fault detection efficiency, so that the platform can efficiently repair the reported faults, and effectively improve the overall stability of the live broadcast business system. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0055] Figure 1 A schematic diagram of a typical network deployment architecture related to implementing the technical solution of this application;

[0056] Figure 2 A flowchart of a typical embodiment of the live broadcast fault detection and processing method of the present application;

[0057] Figure 3 A schematic diagram of the fault reporting control of this application displayed in a graphical user interface;

[0058] Figure 4 A schematic diagram of a graphical user interface of a current live broadcast room when a fault occurs in the current live broadcast room in this application;

[0059] Figure 5 A schematic diagram showing a fault voting control for this application in a graphical user interface;

[0060] Figure 6 A schematic diagram showing the display of the fault notification of the present application in the graphical user interface of the current live broadcast room;

[0061] Figure 7 This is a flow chart of an embodiment executed by a client in the current live studio before the server of the present application responds to a fault reporting event;

[0062] Figure 8 A flowchart diagram of a specific implementation method of calling a text semantic recognition model to detect fault types when a server responds to a fault reporting event in this application;

[0063] Fig. 9 A flowchart diagram of a specific implementation method of calling an audio semantic recognition model to detect a fault type when a server responds to a fault reporting event in this application;

[0064] Fig.10 A flowchart of a specific implementation method of a faulty voting control in a client of a current live broadcast room in this application;

[0065] Fig.11 A flowchart of a specific implementation method for determining the priority of each fault type in this application;

[0066] Fig.12 A flowchart of a specific implementation method of the present application for pushing fault repair patches and receiving feedback information on a server;

[0067] Fig.13This is a principle block diagram of a typical embodiment of a live broadcast fault detection and processing device of the present application;

[0068] Fig.14 This is a basic structural block diagram of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION

[0069] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be interpreted as limiting the present application.

[0070] It will be understood by those skilled in the art that, unless expressly stated, the singular forms "one", "said", and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present application refers to the presence of the features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. It should be understood that when we refer to an element as being "connected" or "coupled" to another element, it may be directly connected or coupled to the other element, or there may be an intermediate element. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The term "and / or" used herein includes all or any unit and all combinations of one or more associated listed items.

[0071] It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as generally understood by those skilled in the art to which this application belongs. It should also be understood that terms such as those defined in common dictionaries should be understood to have meanings consistent with the meanings in the context of the prior art, and will not be interpreted with idealized or overly formal meanings unless specifically defined as here.

[0072] It will be understood by those skilled in the art that the "client", "terminal" and "terminal device" used herein include both devices with wireless signal receivers, which are devices with only wireless signal receivers without transmission capabilities, and devices with receiving and transmitting hardware, which are devices with receiving and transmitting hardware capable of two-way communication on a two-way communication link. Such devices may include: cellular or other communication devices such as personal computers, tablet computers, which have single-line displays or multi-line displays or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service, personal communication system), which can combine voice, data processing, fax and / or data communication capabilities; PDA (Personal Digital Assistant, personal digital assistant), which may include a radio frequency receiver, pager, Internet / intranet access, web browser, notepad, calendar and / or GPS (Global Positioning System, global positioning system) receiver; traditional laptop and / or palmtop computers or other devices, which have and / or include radio frequency receivers. The "client", "terminal" and "terminal device" used herein may be portable, transportable, installed in a vehicle (air, sea and / or land), or suitable and / or configured to run locally, and / or in a distributed form, at any other location on the earth and / or in space. The "client", "terminal" and "terminal device" used herein may also be a communication terminal, an Internet terminal, a music / video playback terminal, such as a PDA, a MID (Mobile Internet Device) and / or a mobile phone with a music / video playback function, or a smart TV, a set-top box and other devices.

[0073] The hardware referred to by the names such as "server", "client", and "service node" in this application is essentially an electronic device with capabilities equivalent to those of a personal computer. It is a hardware device that has the necessary components revealed by the von Neumann principle, such as a central processing unit (including an arithmetic unit and a controller), a memory, an input device, and an output device. The computer program is stored in its memory, and the central processing unit calls the program stored in the external memory into the internal memory for execution, executes the instructions in the program, and interacts with the input and output devices to complete specific functions.

[0074] It should be pointed out that the concept of "server" referred to in this application can also be extended to the case of server clusters. According to the network deployment principle understood by those skilled in the art, the servers should be logically divided. In physical space, these servers can be independent of each other but can be called through interfaces, or integrated into a physical computer or a set of computer clusters. Those skilled in the art should understand this flexibility, and should not use it to restrict the implementation of the network deployment method of this application.

[0075] See also Figure 1 , the hardware foundation required for the implementation of the relevant technical solutions of this application can be deployed according to the architecture shown in the figure. The server 80 referred to in this application is deployed in the cloud. As a business server, it can be responsible for further connecting relevant data servers and other servers that provide relevant support, etc., so as to form a logically related service cluster to provide services for relevant terminal devices such as the smartphone 81 and personal computer 82 shown in the figure or a third-party server (not shown). The smartphone and personal computer can access the Internet through a well-known network access method and establish a data communication link with the server 80 in the cloud to run terminal applications related to the services provided by the server.

[0076] For the server, the application is usually constructed as a service process, opening the corresponding program interface for remote calls by applications running on various terminal devices. The relevant technical solutions suitable for running on the server in this application can be implemented in the server in this way.

[0077] The application described herein refers to an application running on a server or terminal device. This application implements the relevant technical solutions of the present application in a programming manner. Its program code can be stored in a non-volatile storage medium recognizable by a computer in the form of computer executable instructions, and can be loaded into the memory by the central processing unit for execution. The relevant device of the present application is constructed by the operation of the application on the computer.

[0078] For the server, the application is usually constructed as a service process, opening the corresponding program interface for remote calls by applications running on various terminal devices. The relevant technical solutions suitable for running on the server in this application can be implemented in the server in this way.

[0079] For various types of terminal devices that are popular nowadays, especially mobile devices such as tablets and mobile phones, they are usually equipped with built-in imaging devices such as cameras, or personal computers can also be externally connected to the imaging devices. In theory, the application of the terminal device of this application can call the imaging devices in these cases.

[0080] The technical solution in this application suitable for implementation in terminal devices can also be programmed and built into an application that provides live broadcasting as part of its extended functions. The live broadcasting refers to a live broadcast room network service implemented based on the aforementioned network deployment architecture.

[0081] The live broadcast room referred to in this application refers to a video chat room implemented by Internet technology, which usually has audio and video broadcast control functions, including anchor users and audience users. Audience users can include registered users who have registered on the platform, or unregistered visitor users; they can be registered users who follow anchor users, or registered or unregistered users who do not follow anchor users. The anchor user and the audience user can interact through well-known online interactive methods such as voice, video, and text. Generally, the anchor user performs programs for the audience users in the form of audio and video streams, and economic transactions can also be generated during the interaction. Of course, the application form of the live broadcast room is not limited to online entertainment, but can also be extended to other related scenarios, such as education and training scenarios, video conferencing scenarios, product promotion and sales scenarios, and any other scenarios that require similar interactions.

[0082] Those skilled in the art should be aware that, although the various methods of the present application are described based on the same concept and thus present commonality to each other, unless otherwise specified, these methods can be independently executed. Similarly, for each embodiment disclosed in the present application, they are all proposed based on the same inventive concept, therefore, concepts with the same expression, and concepts that are appropriately changed for convenience despite different expressions, should be understood as equivalent.

[0083] See also Figure 2 A live broadcast fault detection and processing method of the present application, in its typical embodiment, comprises the following steps:

[0084] Step S11, responding to the fault reporting event, detecting the fault type existing in the current live studio of the client that triggered the event, and storing the fault information containing the fault type in the fault log:

[0085] The server responds to the fault reporting event to detect the fault type existing in the current live broadcast room of the client, and stores the fault information containing the fault type in the fault log so that the fault information can be broadcast and pushed later.

[0086] The fault reporting event is generally triggered by a client in the live broadcast room, so that the server responds to the fault reporting event, detects the fault type existing in the live broadcast room where the client is located, and then generates the fault information containing the detected fault type for storage.

[0087] The types of failures generally include failures that occur in the live broadcast room, such as the inability of the client in the live broadcast room to send a virtual gift to the anchor, the inability of the audience client in the live broadcast room to receive the live stream pushed by the anchor client, or the inability of the client in the live broadcast room to adjust the volume of the live stream playback.

[0088] The client generally refers to the audience client or the anchor client in the live broadcast room.

[0089] When a fault occurs on the client in the current live broadcast room, the fault reporting text representing the current fault can be edited in the fault reporting control displayed in the current live broadcast room, and the graphical user interface in the current live broadcast room can be screenshoted through the fault reporting control to generate a fault screenshot with an image of the fault occurring in the graphical user interface of the current live broadcast room, and the fault message body including the fault reporting text and the fault screenshot can be pushed to the server, triggering the server to perform fault detection according to the fault message body, and determine the type of fault occurring in the client that pushes the fault message body in the current live broadcast room.

[0090] For details, please refer to Figure 3 and Figure 4 When an error occurs in the current live studio, the client can call out the following in the graphical user interface of the current live studio: Figure 3 In the fault reporting control shown in the figure, the user of the client can edit the fault reporting text through the fault reporting text editing box 301, and can capture the fault reporting text through the screenshot control 302. Figure 4 The graphical user interface of the current live broadcast room shown in the figure shows a fault, and the fault screenshot generated by taking the screenshot will be displayed in the fault screenshot browsing control 303. After completing the editing of the fault report text and the fault screenshot, by touching the push message body control 304 in the fault report control, the client is triggered to generate a fault message body containing the fault report text and the fault screenshot, and the fault message body is pushed to the server so that the server can detect the fault type.

[0091] When the server receives the fault message body pushed by the client in the current live broadcast room, it will parse the fault message body, obtain the fault reporting text and fault screenshot contained in the fault message body, and transmit the fault reporting text to the text semantic recognition model that has been trained to a convergence state. The text semantic recognition model identifies the semantic result of the fault type represented by the fault recognition text, so that the server can obtain the semantic result, determine the fault type represented by the semantic result as the fault type that occurs in the client in the current live broadcast room, and encapsulate the fault type and fault screenshot to generate fault information containing the fault type and fault screenshot, so as to store the fault information in the fault log.

[0092] The fault log is used to store fault information including fault types detected by the server, so that the server can record the faults existing in the live broadcast room through the fault log, and broadcast one or more fault information stored in the fault log to the live broadcast room, inquire whether the client in the current live broadcast room has the fault type represented by the fault information, so as to determine the priority of these fault types, and perform corresponding fault notification and fault repair processing. For the specific implementation methods of broadcasting and pushing the fault information, determining the priority of the fault type, fault notification and fault repair processing, please refer to the specific description of the relevant embodiments in the subsequent steps, and this step will not be repeated.

[0093] In addition to detecting the fault type through the fault message body, the current server can also detect the fault type by monitoring the live audio stream generated by the live broadcast of the anchor client in the current live broadcast room. Specifically, the server transmits the anchor audio stream of the anchor client in the current live broadcast room obtained by monitoring to an audio semantic recognition model that has been trained to a convergence state, obtains the audio recognition result generated by the audio semantic recognition model according to the audio semantic fault reporting text output by the live audio stream, determines the fault type represented by the audio recognition result, generates fault information containing the fault type, and stores the fault information in the fault log.

[0094] Step S12, broadcasting the fault information in the fault log to the current live broadcast room, driving the current live broadcast room to output the fault information to the fault voting control, so as to obtain the fault voting information pushed by the client through the fault voting control:

[0095] The server broadcasts one or more fault information stored in the fault log to the clients in the current live broadcast room, so that after these clients obtain the fault information, they output the fault information to the fault voting control in the graphical user interface of the current live broadcast room for display, so that the fault type existing in the current live broadcast room can be selected from the fault information through the fault voting control, and then the fault voting information containing the fault type corresponding to the selected fault information is pushed to the server for feedback.

[0096] The live broadcast room generally has the fault log for storing its own fault information. The server determines the fault log corresponding to the current live broadcast room and broadcasts all the fault information in the fault log to all clients in the current live broadcast room.

[0097] In one embodiment, the fault log stores fault information corresponding to each live broadcast room, and each fault information carries an identifier of the live broadcast room to which it is associated. When the server needs to broadcast and push fault information corresponding to the current live broadcast room, it will query the fault log for one or more fault information of the live broadcast room identifier corresponding to the current live broadcast room, so as to broadcast the fault information to the client in the current live broadcast room.

[0098] After any client in the current live broadcast room receives all the fault information in the fault log broadcast and pushed by the server, the fault information is output to the fault voting control for display, so that the client can select the fault information through the fault voting control to push the fault voting information. Specifically, the client responds to the fault voting event acting on the fault voting control to generate the fault voting information containing the fault type in the fault information pointed to by the fault voting event, and pushes the fault voting information to the server, so that the server can subsequently determine the priority of each fault type according to the multiple fault voting information pushed by each client in the current live broadcast room.

[0099] Please refer to Figure 5 , Figure 5 This is a schematic diagram of the fault voting control. When any client in the current live broadcast room receives all the fault information in the fault log broadcasted by the server, it outputs the fault information to Figure 5 The fault voting control shown is displayed so that the user can vote for the fault information from the fault voting control. For example, when the user selects the fault information that the live stream cannot be played through the fault voting control shown, by touching the voting control 501 of the fault information, the client will generate fault voting information pointing to the fault type that the live stream cannot be played, and push the fault voting information to the server. Correspondingly, if the client does not encounter a fault in the current live broadcast room, it can vote by touching Figure 5 The cancel voting control 502 that exists in the live broadcast room without any fault is closed, and the display of the faulty voting control in the graphical user interface of the current live broadcast room is closed.

[0100] Step S13, according to the fault voting information, determine the priority of the fault type contained in each fault information in the fault log, select some fault types with higher priority and send corresponding notifications to the current live broadcast room:

[0101] After the server obtains the fault voting information pushed by each client in the current live broadcast room through the fault voting control, it parses and determines the fault type corresponding to each of these fault voting information, and receives the fault voting information corresponding to these fault types through the server to determine the priority corresponding to each of these fault types.

[0102] Specifically, the server counts the number of votes for each fault type according to the fault types pointed to by the fault voting information pushed by each client in the current live broadcast room, and determines the priority of each fault type according to the number of votes corresponding to each fault type. The fault type with a higher number of votes has a higher priority.

[0103] After the server determines the respective priorities of these fault types, it will select the fault types with higher priorities among these fault types, generate fault notifications for these fault types, and push these fault notifications to the client of the anchor end in the current live broadcast room for display, so as to notify the anchor user in the current live broadcast room of the fault types existing in the live broadcast room, so as to facilitate the anchor user and the audience users in the current live broadcast room to communicate about the topic of audience types. Correspondingly, the server can also push the fault notification to the client of the management end in the current live broadcast room, so as to quickly notify the management end to repair the fault type represented by the fault notification, thereby improving the overall fault repair efficiency.

[0104] In one embodiment, the server may broadcast a fault notification containing a higher priority fault type to the client of the current live broadcast room for display, so as to remind the current live broadcast room of the fault type that exists, and the fault notification may contain an estimated repair time for the fault type for display, so as to notify the audience users in the current live broadcast room of the repair time for the fault type.

[0105] Please refer to Figure 6 , Figure 6 This is a schematic diagram of displaying the fault notification in the graphical user interface of the current live broadcast room. The fault notification 601 will be displayed at the top of the layer of the graphical user interface of the current live broadcast room to prompt the client of the type of fault existing in the current live broadcast room.

[0106] It can be understood that the present application performs semantic analysis through the fault feedback of users in the live broadcast room, and monitors the audio stream of the anchor end in the live broadcast room for audio analysis, so as to detect one or more fault types existing in the live broadcast room, and pushes the detected fault information to the client in the live broadcast room for fault consultation, so as to determine whether these fault types exist in most of the clients in the live broadcast room, and then prioritizes the fault types, and predicts whether the fault types existing in the live broadcast room are fault problems existing in the client's equipment or fault problems existing in the business system of the live broadcast room. Generally, the fault types with higher priority are determined as fault problems caused by the business system of the live broadcast room, and a notification message containing the fault types with higher priority is pushed to the anchor end in the live broadcast room for notification, so that the anchor user can understand the faults existing in the live broadcast room, and at the same time, the notification message is pushed to the management end of the live broadcast platform to quickly notify the faults existing in the live broadcast room and improve the efficiency of fault repair.

[0107] The above typical embodiments and their variations fully disclose the implementation scheme of the live broadcast fault detection and processing method of the present application. However, various variations of the method can still be derived by changing and amplifying some technical means. Other embodiments are briefly described as follows:

[0108] In one embodiment, please refer to Figure 3 , Figure 4 and Figure 7 , before the server responds to the fault reporting event, the following pre-steps are performed by the client in the current live broadcast room:

[0109] Step S09, responding to the fault message body editing event, obtaining the fault report text and fault screenshot of the fault report control in the current live broadcast room, wherein the fault report control is used by the client to edit the fault report text and fault screenshot:

[0110] The client in the current live broadcast room responds to the fault message body editing event to obtain the fault device text and fault screenshot of the fault device control in the current live broadcast room.

[0111] The editing of the fault message body is triggered by the user in the client editing the fault report text and fault screenshot through the fault report control in the graphical user interface of the current live broadcast room. For details, please refer to Figure 3 When the client fails in the current live studio, the following message can be displayed in the graphical user interface of the current live studio: Figure 3 The fault reporting control shown in the figure can be used to edit the fault reporting text through the fault reporting text editing box 301 in the fault reporting control, and the screenshot control 302 can be used to capture the fault reporting text. Figure 4The graphical user interface of the current live broadcast room shown in the figure shows a fault. After completing the editing of the fault report text and the fault screenshot, by touching the push message body control 304 in the fault report control, the fault message body editing event is triggered, so that the client responds to the fault message body editing event, generates a fault message body including the fault report text and the fault screenshot, and pushes the fault message body to the server so that the server can detect the fault type.

[0112] Step S10, pushing a fault message body including the fault report text and the fault screenshot to the server, so as to trigger the server to detect the fault type existing in the current live broadcast room according to the fault message body:

[0113] After the client generates a fault message body including the fault reporting text and fault screenshot edited by the user through the fault reporting control in the graphical user interface of the current live broadcast room, the message body is pushed to the server, so that the server detects the fault type existing in the current live broadcast room based on the fault message body.

[0114] In this embodiment, the fault reporting control is designed to provide a fault reporting service to users in the live broadcast room, so that users in the live broadcast room can edit the fault reporting text and fault screenshots through the fault reporting control to feedback the faults existing in the current live broadcast room to the server, thereby triggering the server to call the semantic recognition model to detect the fault type represented by the fault reporting text.

[0115] In one embodiment, please refer to Figure 8 , regarding the specific implementation method of the server responding to the fault reporting event and calling the text semantic recognition model to detect the fault type existing in the current live broadcast room of the client that triggered the event, the specific steps include the following:

[0116] Step S111, receiving the fault message body pushed by the client in the current live broadcast room, and transmitting the fault report text in the fault message body to the text semantic recognition model that has been trained to a convergence state:

[0117] After the server receives the fault message body pushed by the client in the current live broadcast room, it will parse the fault message body, obtain the fault reporting text contained in the fault message body, and transmit the fault reporting text to the text semantic recognition model that has been trained to a convergence state for semantic recognition to determine the fault type represented by the fault reporting text.

[0118] The text semantic recognition model has been trained to a convergence state. It performs semantic analysis by importing the fault report text into a convolutional neural network for recognizing text semantics, and uses normalization processing to classify the fault type of the fault report text that has completed the semantic analysis, and then outputs a semantic result that characterizes the fault type corresponding to the fault report text.

[0119] Step S112, obtaining the semantic recognition result generated by the text semantic recognition model according to the fault report text, and determining the fault type represented by the semantic recognition result:

[0120] The server obtains the semantic recognition result generated by the text semantic recognition model according to the fault report text, determines the fault type represented by the semantic recognition result, and generates fault information containing the fault type.

[0121] Step S113, generating fault information including the fault type and the fault screenshot in the fault message body, and storing the fault information in the fault log:

[0122] The server generates fault information including the fault type and the fault screenshot contained in the fault message body, and stores the fault information in the fault log so that the fault information can be subsequently broadcast to the current live broadcast room for fault voting service.

[0123] In this embodiment, by obtaining the fault message body pushed by the current live broadcast room, and calling the text semantic recognition model that has been trained to a convergence state to perform semantic recognition on the fault reporting text contained in the message body, the fault type represented by the fault reporting text is determined, and fault detection is performed in combination with the neural network model, thereby saving the time spent on manual determination of the fault type and effectively improving the overall efficiency of fault detection.

[0124] In one embodiment, please refer to Fig. 9 , a specific implementation method of the server responding to the fault reporting event, monitoring the live audio stream of the anchor end, and combining the audio semantic recognition model to detect the fault type existing in the current live broadcast room of the client that triggered the event, includes the following specific steps:

[0125] Step S111', monitoring the live audio stream of the anchor client in the current live broadcast room, and transmitting the live audio stream to the audio semantic recognition model that has been trained to a convergence state:

[0126] The server monitors the live audio stream pushed to the media server by the client of the anchor user in the current live broadcast room, so as to obtain the live audio stream and transmit it to the audio semantic recognition model that has been trained to a convergence state for audio recognition, so as to identify the fault type represented by the live audio stream.

[0127] The server transmits the live audio stream to the audio semantic recognition model so that the audio semantic recognition model recognizes the audio semantics output by the live audio stream, and then determines the fault type corresponding to the audio semantics, and then generates an audio recognition result for characterizing the fault type corresponding to the live audio stream.

[0128] Step S112', obtaining the audio recognition result generated by the audio semantic recognition model according to the audio semantics output by the live audio stream corresponding to the fault reporting text, and determining the fault type represented by the audio recognition result:

[0129] The server obtains the audio recognition result generated by the audio semantic recognition model according to the fault reporting text corresponding to the audio semantics output by the live audio stream, determines the fault type represented by the audio recognition result, and generates fault information containing the fault type.

[0130] Step S113', generating fault information including the fault type, and storing the fault information in the fault log:

[0131] The server generates fault information including the fault type, and stores the fault information in the fault log, so as to subsequently broadcast the fault information to the current live broadcast room for fault voting service.

[0132] In this embodiment, the live audio stream of the anchor end in the live broadcast room is monitored today, and the audio semantic recognition model that has been trained to a convergent state is called to perform semantic recognition on the live audio stream to determine the type of fault represented by the live audio stream, so as to determine the fault existing in the current live broadcast room from the audio of the anchor user, and perform fault detection in combination with a neural network model, thereby saving the time spent on manual determination of the fault type and effectively improving the overall efficiency of fault detection.

[0133] In one embodiment, please refer to Figure 5 and Fig.10 , regarding the step of the client of the current live broadcast room receiving the fault information broadcasted by the server, outputting the fault information to the fault voting control, and pushing the fault voting information, including the following steps performed by the client:

[0134] Step S121, obtaining one or more fault information broadcasted by the server, and outputting the fault information to the fault voting control for display:

[0135] After any client in the current live broadcast room receives one or more of the fault information broadcast by the server, it will call up the fault voting control in the graphical user interface of the current live broadcast room to generate the fault information and display it in the fault voting control, so as to select the fault information corresponding to the fault occurring in the current live broadcast room from the fault information displayed in the fault voting control.

[0136] The fault voting control is used to output and display the fault information, and the fault information displayed in the control has a corresponding voting control to perform the selection operation of the fault information. For details, please refer to Figure 5 , Figure 5 This is a schematic diagram of the fault voting control. When any client in the current live broadcast room receives all the fault information in the fault log broadcasted by the server, it outputs the fault information to Figure 5 The fault voting control shown is displayed so that the user can vote for the fault information from the fault voting control. For example, when the user selects the fault information that the live stream cannot be played through the fault voting control shown, by touching the voting control 501 of the fault information, the client will generate fault voting information pointing to the fault type that the live stream cannot be played, and push the fault voting information to the server. Correspondingly, if the client does not encounter a fault in the current live broadcast room, it can vote by touching Figure 5 The cancel voting control 502 that exists in the live broadcast room without any fault is closed, and the display of the faulty voting control in the graphical user interface of the current live broadcast room is closed.

[0137] Step S122, in response to the fault voting event acting on the fault voting control, generating the fault voting information including the fault type in the fault information pointed to by the event:

[0138] The client responds to the fault voting event triggered by the user performing a fault information selection operation through the fault voting control, determines the fault information pointed to by the event, and generates the fault voting information including the fault type in the fault information pointed to by the event.

[0139] Step S123: Push the fault voting information to the server so that the server determines the priority of the fault type according to the fault voting information:

[0140] After the client generates the fault voting information including the fault type in the fault information selected by the fault voting control, the client pushes the fault voting information to the server so that the server determines the priority of the fault type according to the fault voting information.

[0141] In this embodiment, the fault voting control is designed to provide a fault information voting service for users in the live broadcast room, so that users can select the fault type corresponding to the fault occurring in the live broadcast room through the fault voting control, and the client pushes the fault voting information containing the fault type to the server, so that the server can determine the priority of each fault type according to the fault voting information pushed by each client.

[0142] In one embodiment, please refer to Figure 6 and Fig.11 , regarding a specific implementation method in which the server determines the priority of the fault type contained in each fault information in the fault log according to the fault voting information, and selects some fault types with higher priority to send corresponding notifications to the current live broadcast room, including the following specific implementation steps:

[0143] Step S131: according to the fault types pointed to by the fault voting information pushed by each client, the number of votes for each fault type is counted:

[0144] After the server receives the fault voting information pushed by each client in the current live broadcast room, it will determine the fault type to which each of the fault voting information points, and count the number of votes for these fault types of faults according to the number of fault voting information corresponding to these fault types.

[0145] Step S132, according to the vote counts of the fault types, determine the respective priorities of the fault types according to the vote counts:

[0146] After the server has counted the number of votes corresponding to all fault types, it will determine the priority levels corresponding to each of the fault types according to the number of votes corresponding to each of the fault types. For example, when the number of votes for a certain fault type is the highest among all fault types, the priority of this fault type is the highest among these fault types.

[0147] Step S133, generating a fault notification of a fault type with a higher priority, and pushing the fault notification to the target client in the current live broadcast room:

[0148] After the server determines the priorities corresponding to all fault types, it will determine one or more fault types with higher priorities among these fault types to generate a fault notification containing these fault types. Specifically, it generally generates a fault notification containing the first fault type in the priority sorting among these fault types, or generates a fault notification containing the top three fault types in the priority sorting among these fault types.

[0149] After the server generates the fault notification, it pushes the fault notification to the client of the anchor in the current live broadcast room for display, such as Figure 6 The schematic diagram of the display of the fault notification in the graphical user interface of the live broadcast room is shown, so as to notify the anchor user in the current live broadcast room of the fault type existing in the live broadcast room, so as to facilitate the anchor user to communicate with the audience users in the current live broadcast room about the topic of audience type. Correspondingly, the server can also push the fault notification to the client of the management end in the current live broadcast room, so as to quickly notify the management end to repair the fault type represented by the fault notification, thereby improving the overall fault repair efficiency.

[0150] In this embodiment, the priority of each fault type is determined by the number of votes cast by users in the live broadcast room for the fault type, so as to determine the fault type existing in most clients in the current live broadcast room, and generate a fault notification containing the fault type for push notification to notify the anchor user in the current live broadcast room or the management user who manages the live broadcast room of the fault type existing in the current live broadcast room, so as to facilitate the anchor user to adjust the live broadcast business and improve the efficiency of the management user in repairing the fault.

[0151] In one embodiment, please refer to Fig.12 , after the step of determining the priority of the fault type contained in each fault information in the fault log according to the fault voting information, and selecting some fault types with higher priority to send corresponding notifications to the current live broadcast room, it includes:

[0152] Step S14, pushing a fault repair patch for repairing the fault type corresponding to each fault information in the fault log to the client in the current live studio, so as to repair the fault existing in the current live studio:

[0153] After the server obtains the fault repair patch for repairing the fault type existing in the current live broadcast room shown in the fault log, it pushes the fault repair patch to each client in the current live broadcast room so that these clients can repair the faults existing in the current live broadcast room according to the fault repair patch.

[0154] The fault repair patch is generally pushed to the server by the management end of the live broadcast platform. The management end constructs the fault repair patch according to the fault information stored in the fault log and the fault types represented by the fault information, so as to repair the fault types corresponding to the fault information in the fault log in the current live broadcast room.

[0155] Step S15, obtaining the feedback information pushed by the client in the current live broadcast room, and storing the feedback information in the repair log:

[0156] After the client in the current live broadcast room receives the fault repair patch and performs repair, it can push the feedback information representing the repair status of the current live broadcast room to the server. After the server receives the feedback information, it stores the feedback information in the repair log so that the server can push the feedback information to the management end, so that the management end can determine the repair effect of the fault repair patch through the feedback information.

[0157] In this embodiment, a fault repair patch is pushed through the client of the current live broadcast room to repair the fault in the live broadcast room, and feedback information from the client representing the repair status of the patch is collected, so as to understand the user experience after the repair through the feedback information, and then the management user can perform further repairs to improve the user experience of the live broadcast room.

[0158] Furthermore, by functionalizing each step in the method disclosed in the above embodiments, a live broadcast fault detection and processing device of the present application can be constructed. According to this idea, please refer to Fig.13 In a typical embodiment, the device includes: a fault detection module 11, which is used to respond to a fault reporting event, detect the fault type existing in the current live broadcast room of the client that triggers the event, and store the fault information containing the fault type in the fault log; a fault information broadcasting module 12, which is used to broadcast the fault information in the fault log to the current live broadcast room, drive the current live broadcast room to output the fault information to the fault voting control, so as to obtain the fault voting information pushed by the client through the fault voting control; a priority determination module 13, which is used to determine the priority of the fault type contained in each fault information in the fault log according to the fault voting information, and select some fault types with higher priority to send corresponding notifications to the current live broadcast room.

[0159] In one embodiment, the fault detection module 11 includes: a message body receiving submodule, used to receive a fault message body pushed by a client in the current live broadcast room, and transmit the fault reporting text in the fault message body to a text semantic recognition model that has been trained to a convergence state; a semantic recognition result acquisition submodule, used to obtain the semantic recognition result generated by the text semantic recognition model according to the fault reporting text, and determine the fault type represented by the semantic recognition result; a fault information storage submodule, used to generate fault information including the fault type and the fault screenshot in the fault message body, and store the fault information in the fault log.

[0160] In another embodiment, the fault detection module 11 also includes: an audio stream monitoring submodule, which is used to monitor the live audio stream of the anchor client in the current live broadcast room, and transmit the live audio stream to an audio semantic recognition model that has been trained to a convergence state; an audio recognition result acquisition submodule, which is used to obtain the audio recognition result generated by the audio semantic recognition model according to the audio semantic fault reporting text output by the live audio stream, and determine the fault type represented by the audio recognition result; a fault information generation submodule, which is used to generate fault information containing the fault type, and store the fault information in the fault log.

[0161] In one embodiment, the priority determination module 13 includes: a voting number counting submodule, which is used to count the number of votes for each fault type according to the fault type pointed to by the fault voting information pushed by each client; a priority determination submodule, which is used to determine the priority of each fault type according to the number of votes for the fault types; and a fault notification generation submodule, which is used to generate a fault notification for a fault type with a higher priority and push the fault notification to the target client of the current live broadcast room.

[0162] In order to solve the above technical problems, the embodiment of the present application also provides a computer device for running a computer program implemented according to the live broadcast fault detection and processing method. Fig.14 , Fig.14 This is a basic structural block diagram of the computer device in this embodiment.

[0163] like Fig.14 As shown, a schematic diagram of the internal structure of a computer device. The computer device includes a processor, a non-volatile storage medium, a memory, and a network interface connected via a system bus. Among them, the non-volatile storage medium of the computer device stores an operating system, a database, and computer-readable instructions. The database may store a control information sequence. When the computer-readable instructions are executed by the processor, the processor can implement a live broadcast fault detection and processing method. The processor of the computer device is used to provide computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor can execute a live broadcast fault detection and processing method. The network interface of the computer device is used to connect and communicate with a terminal. Those skilled in the art can understand that Fig.14 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0164] In this embodiment, the processor is used to execute the specific functions of each module / submodule in the live broadcast fault detection and processing device of the present application, and the memory stores the program code and various data required to execute the above modules. The network interface is used to transmit data between user terminals or servers. The memory in this embodiment stores the program code and data required to execute all modules / submodules in the live broadcast fault detection and processing device, and the server can call the program code and data of the server to execute the functions of all submodules.

[0165] The present application also provides a non-volatile storage medium, and the live broadcast fault detection and processing method is written into a computer program and stored in the storage medium in the form of computer-readable instructions. When the computer-readable instructions are executed by one or more processors, it means that the program is running in the computer, thereby enabling one or more processors to execute the steps of the live broadcast fault detection and processing method of any of the above-mentioned embodiments.

[0166] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the aforementioned storage medium can be a non-volatile storage medium such as a disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0167] To sum up, the application of the present application can provide fault feedback services to users in the live broadcast room to determine the faults existing in the live broadcast room, and then provide fault notifications, and perform targeted repairs on the collected faults to improve the operating stability of the live broadcast room.

[0168] It should be understood that, although the steps in the flowchart of the accompanying drawings are displayed in sequence as indicated by the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least a part of the steps in the flowchart of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a part of the sub-steps or stages of other steps.

[0169] Those skilled in the art will appreciate that the various operations, methods, steps, measures, and schemes in the processes discussed in this application may be alternated, altered, combined, or deleted. Further, other steps, measures, and schemes in the various operations, methods, and processes discussed in this application may also be alternated, altered, rearranged, decomposed, combined, or deleted. Further, the steps, measures, and schemes in the prior art that are similar to those disclosed in this application may also be alternated, altered, rearranged, decomposed, combined, or deleted.

[0170] The above description is only a partial implementation method of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A live broadcast fault detection and processing method, characterized in that: The steps include: In response to a fault reporting event, detecting the fault type existing in the current live broadcast room of the client that triggered the event, and storing fault information including the fault type in a fault log; Broadcasting the fault information in the fault log to the current live studio, driving the current live studio to output the fault information to the fault voting control, so as to obtain the fault voting information pushed by the client through the fault voting control, wherein the client in the current live studio includes the client of the viewer user; Determine the priority of the fault type contained in each fault information in the fault log according to the fault voting information, select some fault types with higher priority and send corresponding notifications to the current live broadcast room; The step of broadcasting the fault information in the fault log to the current live broadcast room, driving the current live broadcast room to output the fault information to the fault voting control, and obtaining the fault voting information pushed by the client through the fault voting control, includes the following steps performed by the client: Obtain one or more pieces of fault information broadcast by the server, and output the one or more pieces of fault information to the fault voting control for display; In response to a fault voting event acting on the fault voting control, generating the fault voting information including the fault type in the fault information pointed to by the event; The fault voting information is pushed to the server so that the server determines the priority of the fault type according to the fault voting information.

2. The method according to claim 1, characterized in that: Before responding to the fault reporting event, the following pre-steps are performed by the client in the current live studio: In response to the fault message body editing event, the fault report text and the fault screenshot of the fault report control in the current live broadcast room are obtained, and the fault report control is used by the client to edit the fault report text and the fault screenshot; Push a fault message body including the fault report text and the fault screenshot to the server to trigger the server to detect the fault type existing in the current live broadcast room according to the fault message body.

3. The method according to claim 2, characterized in that The step of responding to the fault reporting event and detecting the fault type existing in the current live broadcast room of the client that triggered the event includes the following steps: Receive the fault message body pushed by the client in the current live broadcast room, and transmit the fault report text in the fault message body to the text semantic recognition model that has been trained to a convergence state; Obtaining a semantic recognition result generated by the text semantic recognition model according to the fault report text, and determining a fault type represented by the semantic recognition result; Generate fault information including the fault type and the fault screenshot in the fault message body, and store the fault information in the fault log.

4. The method according to claim 1, characterized in that: The step of responding to the fault reporting event and detecting the fault type existing in the current live broadcast room of the client that triggered the event includes the following steps: Monitor the live audio stream of the anchor client in the current live broadcast room, and transmit the live audio stream to the audio semantic recognition model that has been trained to a convergence state; Obtaining an audio recognition result generated by the audio semantic recognition model according to the audio semantic fault reporting text output by the live audio stream, and determining a fault type represented by the audio recognition result; Fault information including the fault type is generated, and the fault information is stored in the fault log.

5. The method according to claim 1, characterized in that The step of determining the priority of the fault type contained in each fault information in the fault log according to the fault voting information, and selecting some fault types with higher priority to send corresponding notifications to the current live broadcast room comprises the following steps: According to the fault types pointed to by the fault voting information pushed by each client, counting the number of votes for each of the fault types; According to the vote counts of the fault types, determining the respective priorities of the fault types according to the vote counts; Generate a fault notification of a higher priority fault type and push the fault notification to the target client of the current live broadcast room.

6. The method according to any one of claims 1 to 5, characterized in that: After the step of determining the priority of the fault type contained in each fault information in the fault log according to the fault voting information, and selecting some fault types with higher priority to send corresponding notifications to the current live broadcast room, the method further comprises: Pushing a fault repair patch for repairing the fault type corresponding to each fault information in the fault log to the client in the current live broadcast room, so as to repair the fault existing in the current live broadcast room; Obtain the feedback information pushed by the client in the current live broadcast room, and store the feedback information in the repair log.

7. An electronic device, comprising a central processing unit and a memory, characterized in that: The central processing unit is used to call and run a computer program stored in the memory to execute the steps of the method according to any one of claims 1 to 6.

8. A non-volatile storage medium, characterized in that: It stores a computer program implemented according to the method described in any one of claims 1 to 6 in the form of computer-readable instructions, and when the computer program is called and executed by a computer, the steps included in the method are executed.

9. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images