Search the Community

Emby Server: Ubuntu 20.04 on a HP 290 p0043w with 16GB RAM. Hello. Ever since I have upgraded from 4.5 to 4.6, I have to constantly reset my server for Live TV at least once a day or else I get Playback Error after a few hours running, and at one time I had to do it three times. I don't know what is causing it, and I tried looking through the logs but can't spot anything.

I threw this code together fast to get the log data from the HTML page and parse it for reset reason and time. It is a command line application and the only argument is the IP address of the HDHR to look at. Here's pictures of the results for my three HDHomeRun EXTENDs: This screenshot includes the system information from the HDHR (Device ID is very important for figuring out which HDHR is defective): C# source code attached. No copyright, license, or anything. Knock yourself out. The code is fairly self explanatory. HTML parsing is in Program.cs and classes for each HDHR HTML type (log and system) are in the HDHR folder. Those classes take the trimmed HTML (pre for log and table for system) and reorganize the data into memory structures (e.g. HdhrSystem.DeviceId). The class constructor parses the data. The .NET Framework 4.6 executables are in there and, as compiled, they output results formatted in the last picture above when the first argument is a valid HDHR IP. Not incredibly useful but it's a starting point for anyone looking to pull data from the HDHR. This code was only tested using HDHR EXTEND. It should theoretically work on other models but it could theoretically crash too. Shouldn't take much to fix any issues that arise though since it is just reading the HDHR webpages. gethdhrlog.zip

Public Service Announcement Since I've lost two EXTENDs already to "reset reason = application watchdog" I've been paying closer attention to what my EXTENDs do. Here is what they sit at now (number is the last segment of the IP address): 100, new as of a month or so ago. 19700101-00:00:20 System: reset reason = application watchdog 19700101-00:00:20 System: E5592573 0000000E 004E2D68 0042D3A0 00432724 0040D9D0 004DDCEC 004DDCC0 19700101-00:00:20 System: 00506E0C FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 19700101-00:00:20 System: network link 100f 19700101-00:00:21 System: ip address obtained: 192.168.0.100 / 255.255.255.0 20180415-06:00:50 System: time changed from Thu Jan 1 00:00:37 1970 to Sun Apr 15 06:00:50 2018101, about 19 months old and the most used of the three. 19700101-00:00:17 System: reset reason = application watchdog 19700101-00:00:17 System: E5592573 0000000E 004E2D68 0042D3A0 00432724 0040D9D0 004DDCEC 004DDCC0 19700101-00:00:17 System: 00506E0C FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 19700101-00:00:17 System: network link 100f 19700101-00:00:18 System: ip address obtained: 192.168.0.101 / 255.255.255.0 20180401-06:00:53 System: time changed from Thu Jan 1 00:00:34 1970 to Sun Apr 1 06:00:53 2018102, about 19 months old and rarely used. System Log 19700101-00:00:17 System: reset reason = firmware upgrade 19700101-00:00:17 System: network link 100f 19700101-00:00:18 System: ip address obtained: 192.168.0.102 / 255.255.255.0 20180328-21:18:07 System: time changed from Thu Jan 1 00:00:34 1970 to Wed Mar 28 21:18:07 2018102 is perfectly fine so not much to talk about there. 100 and 101 both have the application watchdog message; however, note the time it occurred. It's almost like they deliberately rebooted themselves at 6am. The question is why? Did the log get so full it had to purge it? I don't think this behavior is in error because nothing was recording at the time. Still strange and something to be aware of.