A display device and a display method of a diagnostic dashboard

Abstract

This application discloses a display device and a method for displaying a diagnostic dashboard. The display device is equipped with a monitor and a controller. In response to a screen mirroring standby trigger condition, the controller renders a graphical code for accessing a diagnostic webpage in a first preset area of ​​the user interface, and renders a local diagnostic dashboard in a second preset area that does not overlap with the first preset area. The controller collects local service status information representing the operating status of the screen mirroring service, sends probe packets to the local loopback address based on the local service status information, monitors the local protocol stack's reception of the probe packets to generate monitoring results, and then updates the displayed content of the local diagnostic dashboard according to the local service status information and the monitoring results. This application breaks the information black box of static QR codes, allowing users to predict the device's service readiness status before scanning the code, shortening the troubleshooting path for screen mirroring faults, and improving user experience and screen mirroring diagnostic efficiency.

Description

Technical Field

[0001] This application relates to the field of display device technology, and more particularly to a display device and a display method for a diagnostic instrument panel. Background Technology

[0002] Display devices are intelligent devices capable of presenting a user interface and supporting user interaction. Taking smart TVs as an example, smart TVs are television products based on Internet application technology, equipped with open operating systems and chips, possessing open application platforms, enabling two-way human-computer interaction, and integrating multiple functions such as audio-visual, entertainment, and data to meet diverse and personalized user needs.

[0003] The display device supports wireless screen mirroring, which utilizes the User Datagram Protocol (UDP) multicast mechanism to discover devices within the local area network. For example, the Digital Living Network Alliance (DLNA)'s wireless screen mirroring relies on the Simple Service Discovery Protocol (SSDP), while AirPlay's relies on the Multicast Domain Name System (mDNS). By sending probe messages to a specified multicast address, they identify terminal services within the same network segment and establish a screen mirroring connection. In standby mode for screen mirroring, the large-screen display device typically displays a static graphic code on the display interface. After scanning the code with the terminal, the user is redirected to a diagnostic webpage or connection guidance page, where subsequent network connectivity verification and troubleshooting are performed using a Hypertext Transfer Protocol (HTTP) unicast request.

[0004] However, the static graphic code displayed on the screen to be projected only has a fixed jump indicator function and cannot carry the real-time running status information of the local services of the large screen device. Before scanning the code, users cannot intuitively judge whether the device's own HTTP service, WebSocket service and UDP multicast service are truly ready. As a result, the troubleshooting of screen projection failures has to be initiated blindly from the terminal side. The troubleshooting path is lengthy and it is difficult to quickly locate the root cause on the device side, thus affecting the diagnostic efficiency of screen projection failures and the user's screen projection interaction experience. Summary of the Invention

[0005] This application provides a display device and a method for displaying a diagnostic instrument panel to solve the problem of difficulty in accurately diagnosing screen projection faults in display devices.

[0006] In a first aspect, this application provides a display device, comprising: The monitor is configured to display the user interface; The controller is configured as follows: In response to the screen mirroring standby trigger condition, a graphical code for accessing the diagnostic webpage is rendered in the first preset area of ​​the user interface, and a local diagnostic dashboard is rendered in the second preset area of ​​the user interface, wherein the second preset area does not overlap with the first preset area; Collect local service status information of the display device, which is used to characterize the operating status of the screen projection service in the display device; Based on the local service status information, a probe message is sent to the local loopback address of the display device. The system monitors whether the local protocol stack of the display device receives the probe message in order to generate a monitoring result. The display content of the local diagnostic dashboard is updated based on the local service status information and the monitoring results.

[0007] The above technical solution has the following beneficial effects or advantages: By dividing the standby interface into two independent areas to display the graphic code and the local diagnostic dashboard in parallel, and combining the local loopback detection mechanism to verify the true readiness status of the service port, the information black box of the static graphic code is broken. This allows users to intuitively know the operation status of the local screen projection service of the large screen device before scanning the code, effectively shortening the troubleshooting path for screen projection faults and improving the user experience and efficiency of screen projection diagnosis.

[0008] In some embodiments of this application, the controller sends a probe message to the local loopback address of the display device based on the local service status information, specifically configured as follows: Create a temporary datagram socket; Bind the temporary datagram socket to the target service port to be verified, and set the address reuse option, which allows the temporary datagram socket to be bound to the target service port together with an existing socket; Control the temporary datagram socket to join the multicast group corresponding to the target service port; Generate a probe message carrying a unique sequence number, which is generated by combining the current timestamp with a random number; The probe message is sent to the multicast address and target service port corresponding to the local machine through the temporary datagram socket.

[0009] The above technical solution has the following beneficial effects or advantages: By creating temporary datagram sockets and configuring address reuse options, multicast group joining and probe packet sending operations can be completed without interfering with the normal operation of the original screen projection service port. At the same time, using timestamps combined with random numbers to generate unique sequence numbers to identify probe packets can effectively distinguish probe packets from normal business packets, avoid interference from irrelevant data in the probe process, and improve the accuracy of port status verification.

[0010] In some embodiments of this application, the controller monitors whether the local protocol stack of the display device receives the probe message to generate a monitoring result, specifically configured as follows: Set the receive timeout duration for the temporary datagram socket; Listen for datagram arrivals on the temporary datagram socket; If a data packet is received within the received timeout period, the sequence number in the data packet is extracted and compared with the generated unique sequence number. Based on the matching result, a monitoring result indicating that the port is truly ready is generated. If no data packet is received within the specified reception timeout period, or if the comparison results are inconsistent, a monitoring result indicating a port binding anomaly will be generated.

[0011] The above technical solution has the following beneficial effects or advantages: By setting a receive timeout and performing sequence number consistency comparison on loopback messages, it is possible to accurately determine whether the target port is actually participating in the data transmission and reception process of the kernel protocol stack. This can eliminate false ready judgments where the socket is successfully created but the service is not actually effective in scenarios such as insufficient permissions or system firewall interception. It solves the problem of insufficient accuracy of the judgment method that only checks the existence of processes or sockets, thereby ensuring the authenticity and reliability of service status diagnosis results.

[0012] In some embodiments of this application, the controller collects local service status information of the display device, specifically configured as follows: Collect the listening address and port status of the Hypertext Transfer Protocol service; Collect the listening address and port status of the web socket service; Collect the port binding status and multicast group joining status of at least two multicast services; Collect network configuration information for network interfaces.

[0013] The above technical solution has the following beneficial effects or advantages: Status information is collected from multiple dimensions, including transmission services, long connection services, multicast discovery services, and underlying network configuration, to fully cover the core service modules and network infrastructure on which the screen projection function depends. This ensures that the diagnostic dashboard can fully present the overall operating status of the screen projection link on the device, avoiding missed or incorrect fault diagnosis due to missing information dimensions.

[0014] In some embodiments of this application, when the controller updates the display content of the local diagnostic dashboard, it is specifically configured as follows: Service status entries are arranged in the second preset area. The service status entries include a first status entry for the Hypertext Transfer Protocol service, a second status entry for the WebSocket service, a third status entry for each of the multicast services, and a fourth status entry for the network configuration information. The service status entry displays the service name, port address, multicast address, and corresponding monitoring results, and renders a circular status indicator light at the corresponding position in the service status entry. In response to the port listening status being normal and the monitoring result being that the port is truly ready, the status indicator light is rendered to the first color; In response to an abnormal port listening status or a port binding abnormality detected by the monitoring result, the status indicator light is rendered to a second color; In response to the port binding status being "bound but not yet completed" for the probe packet detection, the status indicator light is rendered to a third color.

[0015] The above technical solution has the following beneficial effects or advantages: By categorizing and arranging multiple service status items, and combining them with a visual design featuring three-color status indicator lights, the health levels of different services can be distinguished intuitively by color. Users can quickly identify the device's operating status without needing to have professional network technical knowledge, which can lower the threshold for understanding diagnostic information and improve the status identification efficiency for non-technical users.

[0016] In some embodiments of this application, the controller, in response to a screen projection standby trigger condition, renders a graphical code in a first preset area of ​​the user interface and a local diagnostic dashboard in a second preset area, specifically configured as follows: Control the width of the first preset area to a first ratio of the total width of the user interface, render the graphic code in the center of the first preset area, and render the scanning guide text below the graphic code; Control the width of the second preset area to a second ratio of the total width of the user interface, and arrange the corresponding service status items vertically within the second preset area; The value of the second ratio is greater than the value of the first ratio.

[0017] The above technical solution has the following beneficial effects or advantages: By optimizing the layout of interface elements by setting the width ratio of the left and right display areas, sufficient space is reserved to display complete diagnostic status information while ensuring sufficient area for graphic code scanning and recognition. This fully utilizes the display space of the display device, achieving a compatible layout for scanning guidance and status display functions, and avoiding overlapping interface elements that may affect visual effects and information reading efficiency.

[0018] In some embodiments of this application, the controller is further configured to: In response to a status query request initiated by the terminal device after scanning the graphic code, the currently cached local service status information and the monitoring results are read. The local service status information and the monitoring results are encapsulated into structured data; The structured data is returned to the terminal device so that the terminal device can render display content locally that is consistent with the local diagnostic dashboard.

[0019] The above technical solution has the following beneficial effects or advantages: By returning structured local status data to the terminal device after scanning the code, the diagnostic information of the display device and the terminal side is mirrored and synchronized, ensuring the consistency of status information at both ends. This not only makes it convenient for users to view the device's operating status on the terminal side, but also provides a unified status reference for remote customer service to assist in troubleshooting, improving the information symmetry of the cross-terminal diagnostic process.

[0020] In some embodiments of this application, the controller is further configured to: After receiving the screen mirroring network diagnostic command sent by the terminal device, query the local service status information and the monitoring results; If at least one status is abnormal or the monitoring result indicates a port binding abnormality, a diagnostic result and repair suggestions for the local service abnormality are returned to the terminal device.

[0021] The above technical solution has the following beneficial effects or advantages: When receiving diagnostic commands from the terminal, the system prioritizes verifying the local service operation status. When a local service anomaly is detected, it directly returns the diagnostic results and corresponding repair suggestions, which can quickly locate device-side faults, avoid users performing ineffective network troubleshooting operations, help users quickly pinpoint the cause of the fault and perform corresponding repair operations, thereby improving the efficiency of troubleshooting screen projection faults.

[0022] In some embodiments of this application, the controller is further configured to: The steps of collecting local service status information and sending detection messages are executed through a background thread; After the background thread completes the steps of collecting local service status information and sending detection messages, the local service status information and the monitoring results are returned to the main display thread. The display content of the local diagnostic dashboard is updated via the main display thread.

[0023] The above technical solution has the following beneficial effects or advantages: By placing the calculation logic for status acquisition and detection message sending in a background thread, separate from the main thread for interface display, the interface rendering process can be prevented from being blocked by periodic detection operations. This ensures the smoothness of the diagnostic dashboard interface refresh and the stability of the graphic code display, thereby improving the smoothness of the user interface and the interactive experience.

[0024] Secondly, this application also provides a method for displaying a diagnostic dashboard, applied to a display device, comprising: In response to the screen mirroring standby trigger condition, a graphical code for accessing the diagnostic webpage is rendered in a first preset area of ​​the user interface, and a local diagnostic dashboard is rendered in a second preset area of ​​the user interface, wherein the second preset area does not overlap with the first preset area. Collect local service status information of the display device, which is used to characterize the operating status of the screen projection service in the display device; Based on the local service status information, a probe message is sent to the local loopback address of the display device. The system monitors whether the local protocol stack of the display device receives the probe message in order to generate a monitoring result. The display content of the local diagnostic dashboard is updated based on the local service status information and the monitoring results.

[0025] The above technical solution has the following beneficial effects or advantages: By combining the local loopback detection to verify the actual status of the port, users can intuitively predict the device's service readiness before scanning the code. It can also quickly locate screen projection failures in some scenarios, thereby improving the user's screen projection experience and screen projection diagnostic efficiency. Attached Figure Description

[0026] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A schematic diagram illustrating display device operation scenarios provided in some embodiments of this application; Figure 2This is a schematic diagram of the hardware configuration of a display device provided in some embodiments of this application; Figure 3 This is a schematic diagram of the software configuration of a display device provided in some embodiments of this application; Figure 4 A schematic flowchart illustrating a diagnostic dashboard display method provided in some embodiments of this application; Figure 5 A schematic diagram of the self-loop detection process provided in some embodiments of this application; Figure 6 A schematic diagram illustrating the process of generating monitoring results provided in some embodiments of this application; Figure 7 A schematic diagram illustrating the interface for updating the diagnostic dashboard provided in some embodiments of this application; Figure 8 Thread diagrams provided for some embodiments of this application; Figure 9 Interaction diagrams illustrating dual-end state synchronization provided for some embodiments of this application; Figure 10 A schematic diagram illustrating the pre-inspection process provided for some embodiments of this application; Figure 11 This is an overall interactive schematic diagram of a diagnostic dashboard display method provided in some embodiments of this application. Detailed Implementation

[0028] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described below do not represent all embodiments consistent with this application. They are merely examples of systems and methods consistent with some aspects of this application as detailed in the claims.

[0029] In this embodiment, display device 200 generally refers to a device with screen display and data processing capabilities. For example, display device 200 includes, but is not limited to, smart TVs, mobile terminals, computers, monitors, advertising screens, wearable devices, virtual reality devices, augmented reality devices, etc.

[0030] Figure 1 This is a schematic diagram illustrating an operational scenario between a display device and a control device provided in some embodiments of this application. For example... Figure 1 As shown, the user can operate the display device 200 via touch operation, terminal device 300, and control device 100. For example, control device 100 can be a remote control, stylus, gamepad, etc.

[0031] The terminal device 300 can function as a control device for human-computer interaction between the user and the display device 200. It can also function as a communication device for establishing a communication connection with the display device 200 and exchanging data. In some embodiments, the terminal device 300 can install software applications with the display device 200 to establish a connection and communication via a network communication protocol, achieving one-to-one control operation and data communication. Furthermore, it can transmit audio and video content displayed on the terminal device 300 to the display device 200 for synchronized display.

[0032] like Figure 1 The diagram also shows that the display device 200 communicates with the server 400 via various communication methods. This allows the display device 200 to communicate via a local area network (LAN), a wireless local area network (WLAN), and other networks.

[0033] Display device 200 can provide broadcast television reception function, and can also be equipped with intelligent network television function that provides computer support function, including but not limited to network television, smart television, Internet Protocol television (IPTV), etc.

[0034] Figure 2 Provided for some embodiments of this application Figure 1 Hardware configuration block diagram of display device 200.

[0035] In some embodiments, the display device 200 may include at least one of a tuner 210, a communication device 220, a detector 230, a device interface 240, a controller 250, a display 260, an audio output device 270, a memory, a power supply, and a user input interface 280.

[0036] In some embodiments, detector 230 is used to collect signals from the external environment or signals interacting with the outside world. For example, detector 230 may include millimeter-wave radar, which can be used to detect whether a user is present within a preset range. Detector 230 may also include a voice acquisition unit to collect voice commands input by the user.

[0037] In some embodiments, the display 260 includes display function components for presenting images and driving components for driving image display. The display 260 is used to receive and display image signals output from the controller 250. For example, the display 260 can be used to display video content, image content, menu control interface components, and user control UI interfaces, etc.

[0038] In some embodiments, the communication device 220 is a component used to communicate with external devices or the server 400 according to various communication protocol types. The display device 200 may have multiple communication devices 220 depending on the supported communication methods. For example, when the display device 200 supports wireless network communication, it may have a communication device 220 with WiFi functionality. When the display device 200 supports Bluetooth connectivity, it needs to have a communication device 220 with Bluetooth functionality.

[0039] The communication device 220 enables the display device 200 to communicate with external devices or the server 400 via wireless or wired connections. Wired connections utilize data cables, interfaces, or other components to connect the display device 200 to external devices. Wireless connections utilize wireless signals or wireless networks. The display device 200 can directly establish a connection with external devices or indirectly through gateways, routers, or other connection devices.

[0040] In some embodiments, the controller 250 may include at least one of a central processing unit, a video processor, an audio processor, a graphics processor, and a power processor, and a first to an nth interface for input / output. The controller 250 controls the operation of the display device and responds to user operations through various software control programs stored in memory. The controller 250 controls the overall operation of the display device 200.

[0041] In some embodiments, the controller 250 and the tuner 210 may be located in different separate devices, that is, the tuner 210 may also be located in an external device of the main device where the controller 250 is located, such as an external set-top box.

[0042] In some embodiments, a user can input user commands through a graphical user interface (GUI) displayed on a display 260, and the user input interface receives user input commands through the graphical user interface (GUI).

[0043] In some embodiments, the audio output device 270 can be a built-in speaker of the display device 200 or an external audio output device connected to the display device 200. For the external audio output device connected to the display device 200, the display device 200 may also be provided with an external audio output terminal, through which the audio output device can be connected to the display device 200 to output sound from the display device 200.

[0044] In some embodiments, the user input interface 280 can be used to receive instructions input by a user. The user input interface 280 may include at least one of a microphone, touchpad, sensor, remote control, etc. The display device 200 can then receive user-input instructions based on the user input interface 280 to perform interactive functions with the user.

[0045] In some embodiments, to enable user interaction, the display device 200 may run an operating system. An operating system is a computer program that manages and controls the hardware and software resources of the display device 200. The operating system can control the display device to provide a user interface; for example, the operating system can directly control the display device to provide a user interface, or it can provide a user interface by running applications. The operating system also allows users to interact with the display device 200.

[0046] It should be noted that the operating system can be a native operating system based on a specific operating platform, a third-party operating system that is deeply customized based on a specific operating platform, or an independent operating system specifically developed for display devices.

[0047] An operating system can be divided into different modules or levels based on the functions it implements, for example... Figure 3 As shown, in some embodiments, the system is divided into four layers, from top to bottom: the Applications layer (referred to as the "Application Layer"), the Application Framework layer (referred to as the "Framework Layer"), the System Library layer, and the Kernel layer.

[0048] In some embodiments, the application layer provides services and interfaces for applications, enabling the display device 200 to run applications and interact with the user based on the applications. The application layer may contain at least one application, which may be a built-in Windows program, system settings program, or clock program of the operating system; or it may be an application developed by a third-party developer. In specific implementations, the application packages in the application layer are not limited to the examples above.

[0049] The framework layer provides application programming interfaces (APIs) and a programming framework for applications. The application framework layer includes predefined functions. It acts as a central processing unit, determining the actions taken by applications within the application layer. Through the API, applications can access system resources and obtain system services during execution.

[0050] like Figure 3As shown, the application framework layer in this embodiment includes a view system, managers, and content providers. The view system designs and implements the application's interface and interactions, and includes lists, grids, text boxes, and buttons. The managers include at least one of the following modules: an activity manager for interacting with all running activities in the system; a location manager for providing system services or applications with access to system location services; a package manager for retrieving various information related to application packages currently installed on the device; a notification manager for controlling the display and clearing of notification messages; and a window manager for managing icons, windows, toolbars, wallpapers, and desktop widgets on the user interface.

[0051] In some embodiments, the Activity Manager manages the lifecycle of individual applications and common navigation and back functions, such as controlling application exit, opening, and back actions. The Window Manager manages all window programs, such as obtaining the screen size, determining if a status bar is present, locking the screen, capturing the screen, and controlling changes to the display window, such as shrinking the display window, shaking the display, or distorting the display.

[0052] In some embodiments, the system runtime library layer can provide support for the framework layer. When the framework layer is used, the operating system runs the instruction library contained in the system runtime library layer, such as the C / C++ instruction library, to implement the functions to be performed by the framework layer.

[0053] In some embodiments, the kernel layer is a functional layer situated between the hardware and software of the display device 200. The kernel layer can implement functions such as hardware abstraction, multitasking, and memory management. For example, ... Figure 3 As shown, hardware drivers can be configured in the kernel layer. The kernel layer can contain at least one of the following drivers: audio driver, display driver, Bluetooth driver, camera driver, WIFI driver, USB driver, HDMI driver, sensor driver (such as fingerprint sensor, temperature sensor, pressure sensor, etc.), and power driver, etc.

[0054] In some embodiments, the display device 200 can implement wireless screen projection functionality. This projection function is based on the User Datagram Protocol (UDP) multicast mechanism to discover devices within a local area network. For example, DLNA's wireless screen projection relies on the Simple Service Discovery Protocol (SSDP), while AirPlay's wireless screen projection relies on the Multicast Domain Name System (mDNS). By sending probe messages to a specified multicast address, terminal service identification and screen projection connection establishment within the same network segment are completed.

[0055] In the standby state for screen projection, the display device 200 displays a static graphic code on the display interface. After scanning the code with the terminal, the user is redirected to a diagnostic webpage or connection guidance page, and subsequent network connectivity verification and troubleshooting are performed using a Hypertext Transfer Protocol (HTTP) unicast request.

[0056] However, the static graphic code displayed on the screen to be projected only has a fixed jump indicator function and cannot carry the real-time running status information of the device's 200 local services. Before scanning the code, users cannot intuitively determine whether the device's own HTTP service, WebSocket service and UDP multicast service are truly ready. This leads to the need to blindly initiate the detection from the terminal side when troubleshooting screen projection failures. The troubleshooting path is lengthy and it is difficult to quickly locate the root cause on the device side, thus affecting the efficiency of screen projection failure diagnosis and the user's screen projection interaction experience.

[0057] To address the aforementioned issues, this application provides a display method for a display device 200 and a diagnostic dashboard. The display device's projection standby interface is divided into two independent preset areas, a first preset area and a second preset area, respectively used to display a graphic code and a local diagnostic dashboard. The local diagnostic dashboard periodically collects local service status information for HTTP, WebSocket, SSDP multicast, mDNS multicast, and network interfaces, and verifies the true readiness status of each service port using a local loopback detection mechanism. The health level of each service is visually indicated using color coding. Users can directly view the device's local projection service operation status on the large screen interface without scanning a code, effectively shortening the troubleshooting path for projection failures.

[0058] In some embodiments, the display device 200 includes a display 260 and a controller 250. The display 260 is configured to display a user interface; the controller 250 is coupled to the display 260 and is used to execute the display process of a diagnostic dashboard.

[0059] Figure 4This is a flowchart illustrating a diagnostic dashboard display method provided in some embodiments of this application. Figure 4 As shown, controller 250 is configured to perform the following steps: S401, In response to the screen mirroring standby trigger condition, render a graphical code for accessing the diagnostic webpage in a first preset area of ​​the user interface, and render a local diagnostic dashboard in a second preset area of ​​the user interface.

[0060] When the display device 200 enters the screen mirroring standby state, the controller 250 triggers the rendering process of the diagnostic dashboard. In some embodiments, the screen mirroring standby triggering conditions include the display device 200 starting the screen mirroring service application, the user opening the screen mirroring function interface via remote control or voice command, or the display device 200 detecting an external screen mirroring request. The controller 250 divides the user interface into two non-overlapping preset areas: a first preset area is used to render graphic codes, and a second preset area is used to render the local diagnostic dashboard.

[0061] In some embodiments, the graphic code can be a QR code or a barcode, and the graphic code encodes the Uniform Resource Locator (URL) address of the diagnostic webpage. The terminal device 300 can automatically access the diagnostic webpage in its browser by scanning the graphic code, without needing to install any dedicated application. The scanning guidance text may include prompts such as "Please use your mobile phone to scan the code for network diagnostics."

[0062] In some embodiments, the diagnostic webpage is a single-page application built on HyperText Markup Language (HTML) and Cascading Style Sheets (CSS). It sends HTTP requests to the display device 200 via XMLHttpRequest or the Fetch API in JavaScript to obtain the latest diagnostic status data. The diagnostic webpage is rendered in a responsive layout in the browser of the terminal device 300, automatically adapting to devices with different screen sizes. The content displayed on the diagnostic webpage is logically divided into three panel areas: the top status summary panel summarizes the overall health status of each service in card format, such as all services are normal or there are N abnormalities; the middle service details panel displays the port addresses, listening status, and probe results of each service (HTTP, WebSocket, SSDP, mDNS) in list format; and the bottom operation panel provides a one-click re-detection button and a network multicast probe startup entry. The diagnostic webpage also has a built-in reconnection and retry mechanism. If the HTTP long polling connection with the display device 200 is interrupted, it automatically attempts to reconnect using an exponential backoff strategy (e.g., intervals of 1 second, 2 seconds, 4 seconds) to ensure the continuity and real-time nature of the status data.

[0063] In some embodiments, the width of the first preset area accounts for a first proportion of the total width of the user interface, such as 40%. A graphic code is rendered centered within the first preset area, and scanning guidance text is rendered below the graphic code. The width of the second preset area accounts for a second proportion of the total width of the user interface, such as 60%. The value of the second proportion is greater than the value of the first proportion. Corresponding service status items are arranged vertically within the second preset area. By setting the width ratio of the left and right display areas, the layout of interface elements is optimized, ensuring sufficient space for graphic code scanning and recognition while reserving enough space to display complete diagnostic status information.

[0064] S402. Collect and display the local service status information of the device.

[0065] While rendering the diagnostic dashboard, controller 250 initiates the local service status acquisition process. The local service status information is used to characterize the operating status of the projection service in display device 200.

[0066] In some embodiments, the controller 250 collects local service status information, including at least one of the following: The system collects the listening address and port status of the Hypertext Transfer Protocol (HTTP) service. The HTTP service provides an interface for diagnosing web resources and querying status to external terminals. The controller 250 determines the HTTP service status by checking whether the HTTP Server's ServerSocket is in an accept connection state and the number of currently active connections.

[0067] The controller collects the listening address and port status of the WebSocket service. The WebSocket service is used to establish long-lived connections with external terminals for bidirectional communication. The controller 250 determines the status of the WebSocket service by checking whether the WebSocket Server port is in a listening state.

[0068] The controller collects the port binding status and multicast group joining status of at least two User Datagram Protocol (UDP) multicast services. UDP multicast services are used to support the SSDP protocol for DLNA screen mirroring and the mDNS protocol for AirPlay screen mirroring. The controller 250 determines the port binding status and multicast group joining status of each multicast service by querying the socket usage of the corresponding ports (such as 1900 and 5353) in the system and whether the service has joined the corresponding multicast group.

[0069] Collect network configuration information for the network interface, including the local IP address, MAC address, and physical connection type (WiFi or wired Ethernet). For example, in the Android platform, controller 250 can obtain the above network configuration information through ConnectivityManager and the NetworkInterface API.

[0070] This embodiment of the disclosure collects status information from multiple dimensions, including transmission services, long connection services, multicast discovery services, and underlying network configuration, which can cover the core service modules and network infrastructure on which the screen projection function depends, ensuring that the diagnostic dashboard fully presents the overall operating status of the screen projection link on the device.

[0071] In some embodiments, when collecting local service status information, the controller 250 sets independent timeout durations and exception handling strategies for each collection dimension. For example, for the port listening status check of the HTTP service, if the ServerSocket query interface does not return a result within 500 milliseconds, the HTTP service is marked as having a collection timeout status, and the status indicator light is rendered in a third color (such as yellow). For the port binding status check of the UDP multicast service, if the system command returns an empty result due to insufficient permissions, the controller 250 may attempt to bind the target service port in exclusive mode. If the binding is successful, the port is released and the status is marked as unbound. If the binding fails and a BindException is thrown (indicating that the port is already in use), the port is marked as bound. In addition, the controller 250 can also maintain a counter for the number of consecutive exceptions. If a service is continuously in an abnormal state for N consecutive collection cycles (such as 3 times), a highlighted prompt is added to the diagnostic dashboard to guide the user to pay attention to this persistent fault.

[0072] S403. Based on local service status information, send a probe message to the local loopback address of the display device.

[0073] After obtaining the local service status information, the controller 250 performs a local loopback probe on each multicast service port to verify whether the service port is actually participating in the data transmission and reception process of the kernel protocol stack.

[0074] Figure 5 This is a schematic diagram illustrating the self-loop detection process provided in some embodiments of this application. For example... Figure 5 As shown, controller 250 is also configured to perform the following steps: S501. Create a temporary datagram socket.

[0075] Controller 250 creates a temporary DatagramSocket to execute this probe task. It is destroyed immediately after the probe is completed, so as not to occupy system resources for a long time.

[0076] S502. Bind the temporary datagram socket to the target service port to be verified and set the address reuse option.

[0077] Controller 250 binds the temporary DatagramSocket to the target service port to be verified (such as the port corresponding to SSDP or mDNS). To avoid port conflicts between the temporary socket and existing service sockets in the system, controller 250 calls the setReuseAddress method to set the SO_REUSEADDR socket option. The address reuse option allows the temporary datagram socket to be bound to the target service port along with an existing socket, thereby completing the probing operation without interfering with the normal operation of the original screen projection service port.

[0078] In some embodiments, if a port is already occupied by an existing screen mirroring service and the operating system does not support the SO_REUSEADDR option, the controller 250 can skip the detection of this port, mark it as an abnormal port binding state, and continue to perform detection on other ports.

[0079] S503: Control the temporary datagram socket to be added to the multicast group corresponding to the target service port.

[0080] Controller 250 adds the temporary DatagramSocket to the target multicast group of the corresponding multicast service. For example, for the SSDP service, it adds it to multicast address A; for the mDNS service, it adds it to multicast address B. After being added to the multicast group, the temporary socket can receive data packets within this multicast group.

[0081] S504. Generate a probe message carrying a unique sequence number.

[0082] The controller 250 generates a probe message, the payload of which contains a unique sequence number. In some embodiments, the unique sequence number is generated by combining the current timestamp with a random number, ensuring that the message identifier for each probe session is globally unique. By carrying a unique sequence number, the probe message and response message can be accurately matched when receiving subsequent loopback messages, avoiding interference from historical residual messages or irrelevant messages on the probe results.

[0083] S505: Send probe packets to the corresponding multicast address and target service port of the local machine through a temporary datagram socket.

[0084] Controller 250 sends the generated probe packets to the corresponding multicast address and target service port on the local machine via a temporary DatagramSocket. Since most operating systems allow local loopback of multicast packets by default, as long as the service port is actually involved in the kernel protocol stack, the sent probe packets will loop back to the local receive buffer via the kernel protocol stack.

[0085] S404. Monitor whether the local protocol stack of the display device receives probe messages in order to generate monitoring results.

[0086] After sending a probe message, controller 250 listens on a temporary DatagramSocket to monitor the loopback reception of the probe message by the local protocol stack. For example... Figure 6 As shown, in some embodiments, the controller 250 sets the receive timeout duration for the temporary datagram socket (S601). For example, the controller 250 calls the setSoTimeout method to set the receive timeout duration of the temporary DatagramSocket to a preset value. It listens for datagram arrival on the temporary datagram socket (S602), such as calling the receive method on the temporary datagram socket to block and wait for datagram arrival. If a datagram is received within the receive timeout duration, the sequence number in the datagram payload is extracted and compared with the generated unique sequence number (S603). If the sequence number matches, it indicates that the local protocol stack has successfully looped back to detect the packet, and the target service port is actually participating in the kernel protocol stack's data transmission and reception process, generating a monitoring result indicating that the port is truly ready (S604). If no datagram is received within the receive timeout duration, or the received datagram sequence number does not match, it indicates that the target service port may have insufficient permissions, system firewall blocking, or other abnormal situations, generating a monitoring result indicating that the port binding is abnormal (S605).

[0087] In the above embodiments, since the operating system of the display device 200 allows local loopback of multicast messages, as long as the service port truly participates in the kernel protocol stack, it will definitely receive the test messages it sends. Conversely, if it does not receive them, it indicates that there is an error in the creation of the Socket, thereby avoiding false readiness errors caused by the existence of the Socket object but the service not being truly ready.

[0088] In some embodiments, the controller 250 starts independent probe sessions for each target service port in a background thread. The probe sessions for different ports are logically isolated from each other and do not interfere with each other.

[0089] In some embodiments, the controller 250 uses a thread-safe counter (such as AtomicInteger) to track the number of currently active probe sessions and presets a maximum number of concurrent probes (e.g., 4). If the number of currently active probe sessions has reached the limit, newly triggered probe requests are queued and executed sequentially in a First In First Out (FIFO) order. After each probe session is completed, the active counter is automatically decremented, and the next probe task to be executed is retrieved from the queue to continue execution. This avoids excessive competition for system resources caused by a large number of concurrent probe threads and ensures the stability of the probe process.

[0090] In addition, in some embodiments, the controller 250 also sets a global timeout protection for each probe session. If the total time from the creation of the temporary DatagramSocket to the receipt of the loopback response (or timeout) exceeds a preset threshold, the probe session is forcibly terminated and the temporary socket resources are released, generating a monitoring result of port binding anomaly, preventing a single probe session from occupying the system handle for a long time.

[0091] S405. Update the display content of the local diagnostic dashboard based on local service status information and monitoring results.

[0092] After completing status acquisition and loop detection, the controller 250 aggregates the local service status information and monitoring results, and drives the display 260 to update the display content of the local diagnostic dashboard in the second preset area.

[0093] Figure 7 These are schematic diagrams illustrating the interface for updating the diagnostic dashboard provided in some embodiments of this application. Figure 7 As shown, in some embodiments, the first preset area displays a graphical code for accessing the diagnostic webpage, and the local diagnostic dashboard arranges service status entries vertically from top to bottom in the second preset area, including a first status entry for HTTP services, a second status entry for WebSocket services, third status entries corresponding to each multicast service (such as SSDP status entries and mDNS status entries), and a fourth status entry for network configuration information. Each service status entry displays the service name, port address, multicast address, and corresponding monitoring results, and a circular status indicator light is rendered at the corresponding position of the service status entry.

[0094] In some embodiments, the status indicator uses a three-color encoding. When the port listening status is normal and the loop detection result shows that the port is truly ready, the status indicator is rendered in the first color (e.g., green), indicating that the service is running normally and is fully ready. When the port listening status is abnormal (e.g., the port is not bound or the process is not started), or the loop detection result shows that the port binding is abnormal (e.g., the loop detection timed out or the sequence number comparison is inconsistent), the status indicator is rendered in the second color (e.g., red), indicating that the service is abnormal. When the port binding status is bound but the loop detection has not yet completed (e.g., detection is in progress or detection timed out), the status indicator is rendered in the third color (e.g., yellow), indicating that the service status is pending confirmation.

[0095] This embodiment of the disclosure uses a categorized arrangement of multiple service status items, coupled with a visual design featuring three-color status indicator lights, to intuitively distinguish the health levels of different services. Users can quickly identify device operating status without needing specialized network technology knowledge, lowering the barrier to understanding diagnostic information. The bottom of the local diagnostic dashboard can also display the timestamp of the most recent status update, such as an update from 3 seconds ago, to help users understand the timeliness of the information.

[0096] In some embodiments, each service status entry in the diagnostic dashboard adopts a fixed three-segment layout. The left segment displays a circular status indicator light; the middle segment displays the service name (e.g., HTTP Diagnostic Service) and service technology identifier (e.g., port number) in two lines of text; and the right segment displays a summary of the monitoring results (e.g., normal operation, port not bound, or firewall may be blocking). For service entries in an abnormal state (red indicator light), an additional fault repair suggestion text is displayed below the middle text, with suggestions pre-set based on common fault types. For example, for an SSDP port not bound, the suggestion is to restart the DLNA projection service; for a loopback detection anomaly, the suggestion is to check if the firewall is allowing the corresponding port and multicast address.

[0097] In some embodiments, the repair suggestion text is rendered with a lighter font color and a slightly smaller font size to create visual hierarchy without interfering with the readability of the main information.

[0098] Figure 8 This is a schematic diagram illustrating threads provided for some embodiments of this application. For example... Figure 8As shown, in some embodiments, to improve the smoothness of interface rendering, the controller 250 executes the steps of local service status information collection and probe message sending through a background thread. The background thread can be implemented using HandlerThread (processor thread) or Kotlin coroutines, performing a complete status collection and loop detection every 3 seconds. After the background thread completes the status collection and probe message sending, it calls back the local service status information and monitoring results to the main display thread through Handler or LiveData, and the main display thread updates the display content of the local diagnostic dashboard.

[0099] In this embodiment, the calculation logic for status acquisition and detection message transmission is executed in a background thread, separate from the main thread for interface display. This avoids periodic detection operations blocking the interface rendering process and ensures the smoothness of the diagnostic dashboard interface refresh and the stability of the graphic code display.

[0100] In some embodiments, the display device 200 supports a status synchronization function with the terminal device 300. Figure 9 The diagram illustrates the interaction of dual-end state synchronization provided in some embodiments of this application. For example... Figure 9 As shown, after the terminal device 300 scans the graphic code, it can initiate a status query request to the display device 200 through a browser. The status query request can be an HTTP GET request, and the request address can be, for example, the IP address of the display device 200 plus a preset path. In response to the status query request initiated by the terminal device 300 after scanning the graphic code, the controller 250 reads the currently cached local service status information and monitoring results (S901), encapsulates the local service status information and monitoring results into structured data (S902), such as JSON format data, and returns the structured data to the terminal device 300 (S903).

[0101] Correspondingly, after receiving the structured data, the terminal device 300 renders the same content in its browser as the local diagnostic dashboard on the display device 200, forming a synchronized dual-end status mirror. This dual-end status synchronization not only allows users to view the device's operating status synchronously on the terminal side, but also provides a unified status reference for remote customer service to assist in troubleshooting, improving information symmetry in the cross-end diagnostic process.

[0102] Building upon dual-end state synchronization, in some embodiments, the diagnostic webpage of the browser on the terminal device 300 can also proactively initiate a persistent state subscription to the display device 200. After initially acquiring structured data, the terminal device 300 initiates a persistent connection request to the display device 200 based on Server-Sent Events (SSE) or WebSocket. After completing each round of state acquisition and loopback detection, the display device 200 proactively pushes the updated diagnostic state data to the terminal device 300 via the persistent connection. Upon receiving the pushed data, the terminal device 300 employs an incremental differential update strategy, only partially redrawing service items whose state has changed, rather than refreshing the entire diagnostic page.

[0103] For example, if only the SSDP service recovers from anomaly to normal during this round of detection, only the indicator light color and summary text of the SSDP status entry are updated, while the remaining entries remain unchanged. Incremental differential updates reduce the computational overhead of page redrawing on the terminal device (300-end) and improve the responsiveness of page interactions. Simultaneously, users can long-press any service entry on the diagnostic webpage to expand a detailed timeline view of that service, displaying the trend of the service's collection results over the most recent N collection cycles in line graph form, facilitating the tracking of patterns in intermittent failures.

[0104] In some embodiments, when the display device 200 receives the screen projection network diagnostic instruction from the terminal device 300, it first performs a local service status pre-check and then decides whether to enter the network multicast detection process (i.e., steps S401-S405). Figure 10 This is a schematic diagram illustrating the pre-inspection process provided in some embodiments of this application. For example... Figure 10 As shown, after receiving the screen projection network diagnostic command sent by the terminal device 300, the controller 250 queries the local service status information and monitoring results (S1001). If at least one status is abnormal or the monitoring result indicates a port binding abnormality, it means that the local screen projection service of the display device 200 itself is not ready. In this case, the controller directly returns the diagnostic result of the local service abnormality and the corresponding repair suggestions to the terminal device 300 (S1002), and skips the subsequent network multicast probe process to avoid sending invalid probe packets to the local area network, thereby reducing network load and diagnostic waiting time. Conversely, if all service statuses are normal and the monitoring results all indicate that the ports are truly ready, the controller can proceed with the network multicast probe process normally, sending SSDP and mDNS probe packets to the local area network multicast address to verify the multicast connectivity between devices within the local area network. The pre-detection and traffic splitting mechanism can quickly locate device-side faults when the local service of the display device is abnormal, avoiding users performing invalid network troubleshooting operations.

[0105] For example, in the network multicast detection process after the pre-detection is passed, the controller 250 sends SSDP multicast search messages and mDNS multicast query messages to the local area network in a preset order. For the SSDP protocol, the controller 250 constructs a request message conforming to the UPnP specification and sends it to the port corresponding to the multicast address via HTTPMU (HTTP Multicast over UDP). The message carries an ST (Search Target) header field, and the search type can be set to discover all UPnP devices in the local area network. After sending the request message, the controller 250 listens for SSDP response messages from other devices in the local area network within a preset waiting window, counting the number and type of responding devices, such as MediaRenderer and MediaServer. Then, the local area network discovery results are sent back to the terminal device 300.

[0106] For the mDNS protocol, controller 250 constructs a query message conforming to RFC 6762 and sends it via multicast to the corresponding port of the multicast address. The query type can be set to discover available AirPlay target devices within the local area network. If no response is received in either SSDP or mDNS probes, it indicates an obstacle in the local area network multicast communication path, such as improper router IGMP Snooping configuration or WiFi client isolation function being enabled. The controller then returns network multicast anomaly diagnostic results and corresponding network configuration check suggestions to terminal device 300.

[0107] Based on the above embodiments, the following examples illustrate the dashboard display content through several specific scenarios.

[0108] Scenario 1: All services are ready and functioning normally.

[0109] The HTTP service port is listening normally, the WebSocket service port is listening normally, the SSDP and mDNS service ports are successfully bound and all multicast groups are joined normally, and the loopback detection returns that the ports are truly ready. At this time, the status indicator lights of all service status entries in the diagnostic dashboard are in the first color (green), and the user can intuitively judge that the device's screen mirroring service is fully ready and can directly initiate a screen mirroring operation.

[0110] Scenario 2: SSDP multicast service is not started.

[0111] The HTTP service port is listening normally, the WebSocket service port is listening normally, the mDNS service port is bound normally and the loopback detection passes, but the SSDP service port is not bound or the process is not started. At this time, the status indicator light of the SSDP status entry in the diagnostic dashboard is the second color (red), and the other entries are green. Users can quickly locate the SSDP service failure and refer to the repair suggestions to restart the screen projection service process.

[0112] Scenario 3: The port is bound but the loopback detection is abnormal.

[0113] The multicast service ports are displayed as bound, but the mDNS service's loopback probe returns a port binding anomaly. At this time, the mDNS status indicator light is the second color (red), indicating that the mDNS socket was successfully created but did not actually participate in the kernel protocol stack's send / receive process, possibly due to system firewall blocking or insufficient permissions. Recommended remediation includes checking system firewall settings or confirming whether the application has network permissions.

[0114] Scenario 4: Detection incomplete.

[0115] As the diagnostic dashboard begins rendering, background threads are collecting status data and performing loopback detection. At this time, the binding status of each multicast service port is "bound," but loopback detection is not yet complete, and the corresponding status indicator light is the third color (yellow). Once the detection is complete, the status indicator light will automatically switch to green or red based on the detection results.

[0116] It should be noted that the above scenarios are only illustrative examples under certain circumstances and do not represent all possible fault scenarios. In actual operation, this solution can also be adapted to other types of service status combinations. Different combinations can correspond to different indicator light colors and repair suggestions, which can cover most abnormal situations in the screen projection network diagnosis process and ensure the comprehensiveness and accuracy of fault location.

[0117] Figure 11 This is an overall interactive schematic diagram of the diagnostic dashboard display method provided in some embodiments of this application. For example... Figure 11 As shown, display device 200 enters the projection standby state, triggering the rendering of the diagnostic dashboard, causing monitor 260 to display the diagnostic dashboard; of course, monitor 260 will also simultaneously display the graphic code used to access the diagnostic webpage. Controller 250 starts a background thread to periodically collect the port listening status, binding status, multicast group joining status, and network interface configuration information of each service (HTTP, WebSocket, SSDP, mDNS), i.e., collect local service status information composed of the above information. The background thread sequentially performs local loopback probes on each multicast service port, generating monitoring results. The background thread calls back the local service status information and monitoring results to the main display thread, which drives the diagnostic dashboard to update the status entries and the colors of the status indicator lights, causing monitor 260 to update the content displayed on the diagnostic dashboard. When terminal device 300 scans the graphic code, it retrieves structured status data from the status query interface of display device 200 via an HTTP request, and renders the same display content as the diagnostic dashboard on the terminal side, achieving dual-end synchronous display of the diagnostic dashboard.

[0118] It should be noted that the diagnostic dashboard display method provided in this application is not only applicable to DLNA projection based on the SSDP protocol and AirPlay projection based on the mDNS protocol, but can also be extended to other mainstream wireless projection technology ecosystems, such as Miracast projection technology.

[0119] In other embodiments, the layout of the first preset area and the second preset area is not limited to a left-right arrangement, but can also be adjusted to a top-bottom arrangement or other layouts according to the display orientation of the display device. For example, in the portrait display mode of the display device 200, the first preset area can be located at the top of the interface, and the second preset area can be located at the bottom of the interface, as long as the two areas do not overlap.

[0120] In other embodiments, the color coding scheme of the status indicator is not limited to green, red, and yellow. Other color combinations or shape symbols can be used according to actual design requirements, such as using checkmark or cross icons, progress rings, and other visual elements to replace color indicator lights, as long as different health levels can be intuitively distinguished.

[0121] In other embodiments, the graphic code is not limited to QR codes and barcodes. It can also use short-range communication methods such as Near Field Communication (NFC) tags or Bluetooth beacons to trigger access to the diagnostic webpage, as long as the terminal device can obtain the access address of the diagnostic webpage.

[0122] Based on the aforementioned display device 200, some embodiments of this application also provide a method for displaying a diagnostic dashboard, which can be applied to the display device 200, such as... Figure 4 As shown, the method includes the following steps: S401. In response to the screen mirroring standby trigger condition, render a graphical code for accessing the diagnostic webpage in a first preset area of ​​the user interface, and render a local diagnostic dashboard in a second preset area of ​​the user interface. The second preset area does not overlap with the first preset area.

[0123] S402. Collect local service status information of the display device. The local service status information is used to characterize the operating status of the screen projection service on the display device.

[0124] S403. Based on local service status information, send a probe message to the local loopback address of the display device.

[0125] S404. Monitor whether the local protocol stack of the display device receives probe messages in order to generate monitoring results.

[0126] S405. Update the display content of the local diagnostic dashboard based on local service status information and monitoring results.

[0127] Based on the above-mentioned diagnostic dashboard display method, the status collection and loop detection results of the local screen projection service can be pre-generated on the display device 200 side. The status is synchronized to the terminal side through graphic codes to complete the mirror display. This does not interfere with the screen projection initiation process and can also help users quickly distinguish whether the fault occurs locally on the display device 200 or on the local area network link, thereby improving the efficiency of screen projection fault diagnosis.

[0128] Similar parts between the embodiments provided in this application can be referred to mutually. The specific implementation methods provided above are only a few examples under the overall concept of this application and do not constitute a limitation on the scope of protection of this application. For those skilled in the art, any other implementation methods extended from the solution of this application without creative effort shall fall within the scope of protection of this application.

Claims

1. A display device, characterized in that, include: The monitor is configured to display the user interface; The controller is configured as follows: In response to the screen mirroring standby trigger condition, a graphical code for accessing the diagnostic webpage is rendered in the first preset area of ​​the user interface, and a local diagnostic dashboard is rendered in the second preset area of ​​the user interface, wherein the second preset area does not overlap with the first preset area; Collect local service status information of the display device, which is used to characterize the operating status of the screen projection service in the display device; Based on the local service status information, a probe message is sent to the local loopback address of the display device. The system monitors whether the local protocol stack of the display device receives the probe message in order to generate a monitoring result. The display content of the local diagnostic dashboard is updated based on the local service status information and the monitoring results.

2. The display device according to claim 1, characterized in that, The controller sends a probe message to the local loopback address of the display device based on the local service status information, specifically configured as follows: Create a temporary datagram socket; Bind the temporary datagram socket to the target service port to be verified, and set the address reuse option, which allows the temporary datagram socket to be bound to the target service port together with an existing socket; Control the temporary datagram socket to join the multicast group corresponding to the target service port; Generate a probe message carrying a unique sequence number, which is generated by combining the current timestamp with a random number; The probe message is sent to the multicast address corresponding to the local machine and the target service port through the temporary datagram socket.

3. The display device according to claim 2, characterized in that, The controller monitors whether the display device's local protocol stack receives the probe message to generate a monitoring result, and is specifically configured as follows: Set the receive timeout duration for the temporary datagram socket; Listen for datagram arrivals on the temporary datagram socket; If a data packet is received within the received timeout period, the sequence number in the data packet is extracted and compared with the generated unique sequence number. Based on the matching result, a monitoring result indicating that the port is truly ready is generated. If no data packet is received within the specified reception timeout period, or if the comparison results are inconsistent, a monitoring result indicating a port binding anomaly will be generated.

4. The display device according to claim 1, characterized in that, The controller collects the local service status information of the display device, specifically configured as follows: Collect the listening address and port status of the Hypertext Transfer Protocol service; Collect the listening address and port status of the web socket service; Collect the port binding status and multicast group joining status of at least two multicast services; Collect network configuration information for network interfaces.

5. The display device according to claim 4, characterized in that, When the controller updates the display content of the local diagnostic dashboard, it is specifically configured as follows: Service status entries are arranged in the second preset area. The service status entries include a first status entry for the Hypertext Transfer Protocol service, a second status entry for the WebSocket service, a third status entry for each of the multicast services, and a fourth status entry for the network configuration information. The service status entry displays the service name, port address, multicast address, and corresponding monitoring results, and renders a circular status indicator light at the corresponding position in the service status entry. In response to the port listening status being normal and the monitoring result being that the port is truly ready, the status indicator light is rendered to the first color; In response to an abnormal port listening status or a port binding abnormality detected by the monitoring result, the status indicator light is rendered to a second color; In response to the port binding status being "bound but not yet completed" for the probe packet detection, the status indicator light is rendered to a third color.

6. The display device according to claim 1, characterized in that, The controller, in response to a screen projection standby trigger condition, renders a graphical code in a first preset area of ​​the user interface and a local diagnostic dashboard in a second preset area, specifically configured as follows: Control the width of the first preset area to a first ratio of the total width of the user interface, render the graphic code in the center of the first preset area, and render the scanning guide text below the graphic code; Control the width of the second preset area to a second ratio of the total width of the user interface, and arrange the corresponding service status items vertically within the second preset area; The value of the second ratio is greater than the value of the first ratio.

7. The display device according to claim 1, characterized in that, The controller is also configured to: In response to a status query request initiated by the terminal device after scanning the graphic code, the currently cached local service status information and the monitoring results are read. The local service status information and the monitoring results are encapsulated into structured data; The structured data is returned to the terminal device so that the terminal device can render display content locally that is consistent with the local diagnostic dashboard.

8. The display device according to claim 7, characterized in that, The controller is also configured to: After receiving the screen mirroring network diagnostic command sent by the terminal device, query the local service status information and the monitoring results; If at least one status is abnormal or the monitoring result indicates a port binding abnormality, a diagnostic result and repair suggestions for the local service abnormality are returned to the terminal device.

9. The display device according to claim 1, characterized in that, The controller is also configured to: The steps of collecting local service status information and sending detection messages are executed through a background thread; After the background thread completes the steps of collecting local service status information and sending detection messages, the local service status information and the monitoring results are returned to the main display thread. The display content of the local diagnostic dashboard is updated via the main display thread.

10. A method for displaying a diagnostic instrument panel, characterized in that, Applied to display devices, including: In response to the screen mirroring standby trigger condition, a graphical code for accessing the diagnostic webpage is rendered in a first preset area of ​​the user interface, and a local diagnostic dashboard is rendered in a second preset area of ​​the user interface, wherein the second preset area does not overlap with the first preset area. Collect local service status information of the display device, which is used to characterize the operating status of the screen projection service in the display device; Based on the local service status information, a probe message is sent to the local loopback address of the display device. The system monitors whether the local protocol stack of the display device receives the probe message in order to generate a monitoring result. The display content of the local diagnostic dashboard is updated based on the local service status information and the monitoring results.

Images