Issue with DLNA server causing reboot loop

M

mergwyn

New Member
Hi,

I've been running the custom firmware happily for many, many years, but this week all that has changed. Since Tuesday my humax has been rebooting after 3-5 minutes running. I've tried following the guide for resolving reboot issues: https://hummy.tv/forum/threads/steps-for-resolving-hdr-fox-crash-reboot-issues.5320/ and have run fix-disk with no apparent errors, and through a process of trial and error have got to the point where I have discovered the Humax is stable if I disable content sharing and reboots if it is enabled.

Looking at step 2C in the guide, I have booted with the network unplugged (I use a WiFi dongle) and the reboots still occur when content sharing is enabled and stop when not enabled. Does this seem to suggest that the issue is on the humax rather than a a conflict on my network?

I use webIF recessive decrypt (and sweeper) but disabling decrypt and emptying the queue still results in the rebooting issue.

I've installed crashdiag and this is what it shows:
Code: 
*********** Core file /mod/core/humaxtv.1628759080.257 ***********
Thu Aug 12 10:04:40 BST 2021
Core was generated by `/usr/bin/humaxtv'.
Program terminated with signal 10, Bus error.
#0  0x62616b72 in ?? ()
[Current thread is 1 (Thread 3397)]
Thread
#0  0x62616b72 in ?? ()

Thread 109
#0  0x2c52ee3c in recvmsg () from /lib/libpthread.so.0
#1  0x2c52ee20 in recvmsg () from /lib/libpthread.so.0

Thread 108
#0  0x2c5416bc in ioctl () from /lib/libc.so.0
#1  0x2c01e24c in ?? () from /usr/lib/libnexus.so

Thread 83
#0  0x2c52ee3c in recvmsg () from /lib/libpthread.so.0
#1  0x2c52ee20 in recvmsg () from /lib/libpthread.so.0

Thread 69
#0  0x2c52e5dc in read () from /lib/libpthread.so.0
#1  0x2c52e5c0 in read () from /lib/libpthread.so.0

Thread 67
#0  0x2c542c20 in select () from /lib/libc.so.0
#1  0x008fd36c in ?? ()

Thread 4
#0  0x2c52ea6c in accept () from /lib/libpthread.so.0
#1  0x2c52ea50 in accept () from /lib/libpthread.so.0

Thread 3
#0  0x2c542c20 in select () from /lib/libc.so.0
#1  0x0089b848 in ?? ()

So I turned on humaxtv logging and this is what the end of the log shows
Code: 
adding dns 10.58.0.22


IP Address List: 192.0.2.100, 10.58.0.156


mxDLNA [DLNA DMS DmsRunThread] Start (PID:212   TID:1039103184).......


[mxDlnaFileScanner_create] +++++


[mxDlnaFileScanner_addDirectory] SEARCH_LIST_PATH_EXACT_MATCHED


[mxDlnaFileScanner_create] -----


[mxDlnaFileScanner_addDirectory] SEARCH_LIST_PATH_EXACT_MATCHED


[mxDlnaFileScanner_addDirectory] SEARCH_LIST_PATH_EXACT_MATCHED


[mxDlnaFileScanner_addDirectory] SEARCH_LIST_PATH_EXACT_MATCHED


[ifss_start] +++++

There is nothing obvious in other logs but am happy to provide more information if it will help.

So far I have held off reformatting the disk as there is nothing that seems to indicate it would resolve the issue.

I am running on the 3 .13 firmware and the installed packages are up to date. As far as I am aware, I have not changed any settings on the humax for some time.

So, I've run up against brick wall! I can turn content sharing off and the box is stable, but then I can't decrypt the content automatically and make it available on my Plex server. So I have a work around that allows me to keep watching and recording content but does not meet my requirements in the medium / long term.

I'd be really grateful for any advice / guidance that you are able to provide that might help me find a way forward.
 
Install the dlna-filter package, and check its configuration on the WebIf's setup page.
 
prpr said:
Install the dlna-filter package, and check its configuration on the WebIf's setup page.
Click to expand...
Thanks. My bad, I should have included that. I installed DLNA-filter package yesterday. The address field is left empty - is that correct?
 
That filters everything, so should be safe.
If you want to check, then do this from the command line:
Code: 
humax ~ # iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination       
DROP       tcp  --  anywhere             anywhere            tcp dpt:50001
If it's still crashing then I would suggest a DLNA database reset on the Diags page, and see what happens next.
If it carries on crashing, then you've possibly got a corrupt media file somewhere on the disk that needs deleting.
 
Last edited:
Thanks. I've just checked iptables and the output is the same as yours.

I have already reseting the DLNA database (and for that matter also did a 'System Flush'), but again it did not resolve the issue.

Any ideas on how to identify which media file might be corrupt? Is it as simple as looking at everything created since Monday and eliminating them one by one?

Is it possible to increase logging somehow?
 
mergwyn said:
Any ideas on how to identify which media file might be corrupt? Is it as simple as looking at everything created since Monday and eliminating them one by one?
Click to expand...
It may or may not be something recent that is corrupt, so the latter may or may not work, but might be worth a try.
The only other way is divide and conquer (binary search) - move half the recordings to where the DLNA indexer can't see them and see what happens. If it stops, the faulty one is in the bunch just moved, so move half of them back and repeat. If not, then it's one (or more) of the ones that remain, so repeat the process.
It's dull and time-consuming and you need a plan for keeping track. Obviously the more files you have the bigger the problem is.
 
MymsMan said:
When trying to identify rogue recordings I have had some some success looking to see which files are unexpectedly inuse.
See https://hummy.tv/forum/threads/health-of-hdd-after-fix-disk.9308/post-133568

I have mainly used it when the system is failing to shut down correctly but it may also help in your circumstances
Click to expand...
Thanks for the suggestion. I put the lsof command in a loop and repeated every 2 seconds and then enabled content sharing but the only file that was open was
Code: 
/mnt/hd2/Tsr/0.ts
So unfortunately no clues there.
 
prpr said:
It may or may not be something recent that is corrupt, so the latter may or may not work, but might be worth a try.
The only other way is divide and conquer (binary search) - move half the recordings to where the DLNA indexer can't see them and see what happens. If it stops, the faulty one is in the bunch just moved, so move half of them back and repeat. If not, then it's one (or more) of the ones that remain, so repeat the process.
It's dull and time-consuming and you need a plan for keeping track. Obviously the more files you have the bigger the problem is.
Click to expand...
Thanks - I'll try this later today when I have more time. Where can I find a list of the locations where the DLNA indexer looks? Or is it '/mnt/hd2/My*'?
 
mergwyn said:
Or is it '/mnt/hd2/My*'?
Click to expand...
Practically speaking, just "My Video". I presume you don't have anything in Music or Photo.
I would be tempted to create something like /mnt/hd2/stuff and move everything from /mnt/hd2/My\ Video into it and see whether that stops the crashes.
If it does, then do the binary search process described previously.
 
Thanks to your help in pointing me in the right direction, I have found and corrected the issue, though it was created by me in the first place!

I turns out it wasn't a corrupt file but some poorly placed symbolic links that created a recursive loop that eventually caused the DLNA indexer to crash. I have a script (that runs on my NAS) which copies files off the humax onto my NAS so that my humax content can be made available via plex. Part of this process is to treat series that I have identified via IMDB differently so that they appear in plex as TV series and not individual videos. I do this by creating a symbolic link from a separate folder to the folders for the TV series. Something went wrong such that my script created a symbolic link from a directory to itself (eg My Video/TVseries -> ../TVseries). Now all I have to do is figure out where the bug is in my script!

Thanks again for you support, it is much appreciated.
 
Last edited:
You must log in or register to reply here.
Back
Top