Crashing HDR Fox T2

jonathan_london

New Member
Hi

My Humax won't stay up for more than a minute...

>>> Contents of /mod/tmp/crash.log 1012 bytes Humax crashed at Tue Mar 11 04:20:53 GMT 2014 - Uptime: 181
Humax crashed at Tue Mar 11 22:14:53 GMT 2014 - Uptime: 66
Humax crashed at Tue Mar 11 22:16:24 GMT 2014 - Uptime: 68
Humax crashed at Tue Mar 11 22:21:21 GMT 2014 - Uptime: 273
Humax crashed at Tue Mar 11 22:22:52 GMT 2014 - Uptime: 66
Humax crashed at Thu Mar 13 04:20:55 GMT 2014 - Uptime: 111
Humax crashed at Thu Mar 13 21:56:09 GMT 2014 - Uptime: 66
Humax crashed at Fri Mar 14 04:20:54 GMT 2014 - Uptime: 110
Humax crashed at Sat Mar 15 04:20:54 GMT 2014 - Uptime: 110
Humax crashed at Mon Mar 17 04:20:53 GMT 2014 - Uptime: 180
Humax crashed at Tue Mar 18 04:20:54 GMT 2014 - Uptime: 110
Humax crashed at Tue Mar 18 20:53:22 UTC 2014 - Uptime: 8028
Humax crashed at Tue Mar 18 20:54:55 UTC 2014 - Uptime: 68
Humax crashed at Wed Mar 19 01:09:29 UTC 2014 - Uptime: 67
Humax crashed at Wed Mar 19 01:11:00 UTC 2014 - Uptime: 68
Humax crashed at Wed Mar 19 01:12:30 UTC 2014 - Uptime: 67
Humax crashed at Wed Mar 19 01:14:00 UTC 2014 - Uptime: 67


I have booted it in diag mode (telnet) and checked the disk for bad blocks. It found one in
/mnt/hd2/mod/monitor/monitor.db
which I repaired (and it has done this once before, several months ago). Fix-disk then ran to
completion, as did another "run long hard-disk self test".

I then took the opportunity to upload the latest Humax firmware and customised firmware. The
machine ran for a couple of hours before crashing again. When it crashes, on the TV the audio
continues but the video freezes. After about a minute, it reboots.

smartctl reports:

humax# smartctl -A /dev/sda
smartctl 5.41 2011-06-09 r3365 [7405b0-smp-linux-2.6.18-7.1] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 114 066 006 Pre-fail Always - 348673
3 Spin_Up_Time 0x0003 095 093 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 098 020 Old_age Always - 1
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 075 060 030 Pre-fail Always - 0
9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 3370
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 099 099 020 Old_age Always - 1690
184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 001 001 000 Old_age Always - 65535
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 064 034 045 Old_age Always In_the_past 36 (2 24 43 36)
194 Temperature_Celsius 0x0022 036 066 000 Old_age Always - 36 (0 17 0 0)
195 Hardware_ECC_Recovered 0x001a 030 016 000 Old_age Always - 348673
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0

and hdinfo reports

Running: hdinfo

/dev/sda:

ATA device, with non-removable media
Model Number: ST31000424CS
Serial Number: 5VX2HP32
Firmware Revision: SC13
Transport: Serial
Standards:
Used: unknown (minor revision code 0x0029)
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1953525168
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
cache/buffer size = 16384 KBytes
Nominal Media Rotation Rate: 5900
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = ?
Advanced power management level: 192
Recommended acoustic management value: 254, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
Power-Up In Standby feature set
SET_FEATURES required to spinup after power up
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* Media Card Pass-Through
* General Purpose Logging feature set
* 64-bit World wide name
Write-Read-Verify feature set
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Native Command Queueing (NCQ)
* Phy event counters
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT Read/Write Long (AC1), obsolete
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
unknown 206[12] (vendor specific)
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
186min for SECURITY ERASE UNIT. 186min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000c5004496a2e0
NAA : 5
IEEE OUI : 000c50
Unique ID : 04496a2e0
Checksum: correct

and general reports

Running: general

*** Directory Structure ***

Checking /mod partition type : Pass
Checking /mod filesystem type : Pass
Checking /mod/tmp directory exists : Pass
Checking /mod/var/opkg/tmp is a directory : Pass
Checking /mod/boot is a symlink : Pass
Checking /var/lib/humaxtv/mod is a directory : Pass
Checking /var/lib/humaxtv_backup/mod is a directory : Pass
Checking /mod/boot/2 is a symlink : Pass
Checking /mod/boot links correctly : Pass
Checking /mod/boot/2 links correctly : Pass

and I've run other diags too, all of which look good. I have run fix-flash-packages, and removed
all old portal applications. I have also tried a full mains power cycle.

After starting up, I have noticed the web interface soon complains it cannot find the humaxtv process,
and I assume that's what leads to a reboot. But why is that process quitting.

Where should I look next?

Thanks,
Jonathan.
 
Have you tried a full cold restart (from mains off)?

I don't think this is it, but as a diagnostic: try turning off content sharing (this will prevent on-the-box decryption, so not a permanent solution); try disconnecting the network. Does the crashing stop with either of these in place?

Menu >> Settings >> System >> Internet Setting >> Content Share = Off

Presuming these have no effect, I would be inclined to reflash the firmware (starting with a standard firmware, see if the box behaves properly at all).
 
Have you tried a full cold restart (from mains off)?

Thanks for your suggestions! As mentioned above, I had tried a power-cycle.

I don't think this is it, but as a diagnostic: try turning off content sharing (this will prevent on-the-box decryption, so not a permanent solution); try disconnecting the network. Does the crashing stop with either of these in place?

Menu >> Settings >> System >> Internet Setting >> Content Share = Off

Thanks. I have just booted without the network cable in, and it stayed up for more than a minute, so I was able to turn off Content Sharing. I plugged in the network cable, and it stayed up, so I have rebooted (cable in) and so far, so good. However, it did last 8,028 seconds on Tuesday, so that's not conclusive :) I have cleared down the log files, so let's see what happens.

Presuming these have no effect, I would be inclined to reflash the firmware (starting with a standard firmware, see if the box behaves properly at all).
I have tried two different firmwares. I agree that the next step is an RMA, and standard firmware.

I am not (consciously) content sharing, but there are all sorts of devices on my network (Mac, WIndows, Linux, Android, printers). I'm not aware of anything changing, which is why my first thought was a disk fault.

Many thanks for your help!

Jonathan.
 
If there is a problem only when content share = on and your Humax is connected to your LAN, you may have something on your LAN that the Humax clashes with, e.g. Twonky ver7, there are some notes on the Wiki HERE
 
If there is a problem only when content share = on and your Humax is connected to your LAN, you may have something on your LAN that the Humax clashes with, e.g. Twonky ver7, there are some notes on the Wiki HERE

Thanks, you've both helped me to home in on the problem. After leaving the Humax running all afternoon without a crash (and on the network), everything seemed happy. So I decided to try my luck and force a decryption on a file. Here's the results:

Code:
Processing The Italian Job_20131228_1901
Moving recording to /media/My Video/[Films]/_original
Runtime Error: execute.jim:52: error copying "/media/My Video/[Films]/The Italian Job_20131228_1901.ts.decrypting" to "/media/My Video/[Films]/The Italian Job_20131228_1901.ts": file already exists
in procedure 'file' called at file "execute.jim", line 52


Shortly after this (within 60 seconds?) the Humax rebooted, and rebooted, until I unplugged the network cable. At which point I was able to turn off sharing, and reconnect the network.

I am running:

Code:
Web interface version: 1.0.10-1
Custom firmware version: 2.22 (build 1905)
Humax Version: 1.03.12

crash.log contains

Code:
Humax crashed at Wed Mar 19 18:56:42 UTC 2014 - Uptime: 22154
Humax crashed at Wed Mar 19 18:58:24 UTC 2014 - Uptime: 71

unencrypt.log is zero bytes.

Any thoughts on where to turn next?

Thanks,
Jonathan.
 
Take it off the network and turn on content sharing and see what happens.
Is the .ts file corrupt? Does it play? You might have to do some manual cleanup based on the files named in the error messages.
 
Quick update. It's been running fine for a couple of days with Content Share = Off. So I created /var/lib/humaxtv/mod/debugtv and tailed /tmp/humaxtv.log

This is what happens:

Code:
humax# tail -f humaxtv.log
Domain      :.bbc.co.uk
CertPath    :hdrfoxt2_20101001.p12
###### New Cert is Added
########################################
########################################
Domain      :.bbc.co.uk
CertPath    :rootcert_1k.pem
###### New Cert is Added
########################################
[syncBoxInfo:1240]

Turn Content Share = On

Code:
IP Address List: 192.168.1.66
mxDLNA [DLNA DMS DmsRunThread] Start (PID:234  TID:1043846352).......
[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] +++++
Posttvcrash - uptime: 134
Slow crash - not removing plugins
Connection closed by foreign host.

Any thoughts?

Thanks,
Jonathan.
 
If all the lines below are true, then (as stated in #4) it is very likely that something on your LAN is causing the crash, I would temporarily disconnect, or turn off other P.C.s, laptops, NASs etc. on your LAN and try set-up 3, if there is no crash, slowly re-introduce the disconnected items to to see what makes it crash.

Set-up 1) Content Share = Off and LAN cable connected = no crash
Set-up 2) Content Share = On and LAN cable disconnected = no crash
Set-up 3) Content Share = On and LAN cable connected = crash
 
There is indeed something funny about network config -
I'm now talking about a box with factory 1.3.11 FW on it - unmodified:
Run the box (from new) no problem for 3 days.
Box tuned to RT (channel 85) - normally no problem
Plug in a tenda Wifi adaptor - wifi setup stays gray
The box reboots/crashes every 60 seconds
change channel to say Ch19 "Yesterday" (on same mux)
or any other channel
Box stops crashing
Tune back to ch85
every 60 seconds it crashes again
Change to BBC or whatever - it stops crashing
Remove Wifi - then plug in ethernet cable
Set up a wired connection
Works fine - no crashes anywhere
remove cable - re-install wifi adaptor
Wifi setup enables itself
Sets up and works perfectly. No crashes (sunday)
The router in use has nothing else plugged into it - just its wifi turned on for the humax.
"I believe" there may be a bug somewhere in the the network setup that can cause physical crashing.
I have seen this on 3 diffrent humax boxes all with 1.3.11 AND 1.3.12 firmware now although triggering
the crashes varies somewhat. The symptoms are always channel 85 selection causing crashes
every 60 seconds - even if no wifi is plugged in however.
A box on the same aerial with 1.2.32 firmware (Mod 2.21 - but no additions) show no inclination to crash
even using the same wifi stick.
Something is not right here - I'm guessing in network code because I reproduced it 3 times before installing the
cabled settings.
Its currently working fine with or without wifi.
 
Take it off the network and turn on content sharing and see what happens.
Is the .ts file corrupt? Does it play? You might have to do some manual cleanup based on the files named in the error messages.

Thanks for everyone's help. It turns out that I have two problems, which was making it harder to understand what was going on.

Problem 1

The .ts file is just fine. It turns out that decrypt from the web interface fails for folders with square brackets in the name. Here's the example from earlier

Code:
Processing The Italian Job_20131228_1901
Moving recording to /media/My Video/[Films]/_original
Runtime Error: execute.jim:52: error copying "/media/My Video/[Films]/The Italian Job_20131228_1901.ts.decrypting" to "/media/My Video/[Films]/The Italian Job_20131228_1901.ts": file already exists
in procedure 'file' called at file "execute.jim", line 52

The problem is the file /mod/var/mongoose/html/browse/decrypt/execute.jim. The glob in the for loop

foreach f [glob -nocomplain "${base}.*"] {

doesn't match any files, if there are [] in $base, and therefore the .ts file isn't moved to the _original so the next rename of the .ts.decrypted file fails.

Renaming the folder, losing the [], and re-indexing the DLNA server fixes everything, and the files can then be decrypted.

Problem 2

As predicted, it appears Twonky Beam was running on the network. My Humax ran fine connected back-to-back to a Mac with sharing enabled. I was able to decrypt files (providing they didn't have [] in the path). I then shut down two mobile phones, two tablets, and a Windows laptop. and reconnected the Humax and Mac to the network. Everything fine. Then I reintroduced all the devices, and still fine. Then I fired up TwonkyBeam on an Android tablet, and the Humax crashed. I conclude at this point that TwonkyBeam was running on the tablet previously, even though the tablet wasn't in use.

Packet trace follows - from TwonkyBean starting, to Humax crashing. Tablet using IP address 192.168.1.17:

Code:
16:54:06.164125 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 129
16:54:06.206653 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 127
16:54:06.254942 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 137
16:54:06.305743 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 129
16:54:06.355458 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 127
16:54:06.414129 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 136
16:54:06.455981 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 136
16:54:06.506294 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 137
16:54:06.556719 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 118
16:53:02.826523 IP 192.168.1.17.54546 > humax.50001: S 2349778940:2349778940(0) win 14600 <mss 1460,sackOK,timestamp 84593[|tcp]>
16:53:02.828223 IP 192.168.1.17.54546 > humax.50001: . ack 4172896969 win 229
16:53:02.832969 IP 192.168.1.17.54546 > humax.50001: P 0:162(162) ack 1 win 229
16:53:02.949111 IP 192.168.1.17.54546 > humax.50001: . ack 16 win 229
16:53:02.978910 IP 192.168.1.17.54546 > humax.50001: . ack 44 win 229
16:53:03.025340 IP 192.168.1.17.54546 > humax.50001: . ack 1504 win 274
16:53:03.050563 IP 192.168.1.17.54546 > humax.50001: . ack 1628 win 274
16:53:03.073893 IP 192.168.1.17.54546 > humax.50001: F 162:162(0) ack 1629 win 274
16:53:03.170471 IP 192.168.1.17.54547 > humax.50001: S 3078279424:3078279424(0) win 14600 <mss 1460,sackOK,timestamp 84594[|tcp]>
16:53:03.417651 IP 192.168.1.17.54547 > humax.50001: . ack 4175927746 win 229
16:53:03.418181 IP 192.168.1.17.54547 > humax.50001: P 0:187(187) ack 1 win 229
16:53:03.419297 IP 192.168.1.17.54547 > humax.50001: . ack 16 win 229
16:53:04.364722 IP 192.168.1.17.54547 > humax.50001: . ack 44 win 229
16:53:04.401506 IP 192.168.1.17.54547 > humax.50001: . ack 1504 win 274
16:53:04.483625 IP 192.168.1.17.54547 > humax.50001: . ack 2964 win 320
16:53:04.486337 IP 192.168.1.17.54547 > humax.50001: . ack 4424 win 365
16:53:04.683890 IP 192.168.1.17.54547 > humax.50001: F 187:187(0) ack 5487 win 411
16:53:04.686487 IP 192.168.1.17.54548 > humax.50001: S 1105725619:1105725619(0) win 14600 <mss 1460,sackOK,timestamp 84597[|tcp]>
16:53:04.687869 IP 192.168.1.17.54548 > humax.50001: . ack 4171773781 win 229
16:53:04.691562 IP 192.168.1.17.54548 > humax.50001: P 0:167(167) ack 1 win 229
16:53:04.785011 IP 192.168.1.17.54548 > humax.50001: . ack 133 win 245
16:53:04.829908 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 117
16:53:04.832275 IP 192.168.1.17.9010 > humax.52127: S 3590740572:3590740572(0) ack 4186197170 win 14600 <mss 1460,nop,nop,sackOK,nop,wscale 6>
16:53:04.922588 IP 192.168.1.17.9010 > humax.52127: . ack 463 win 245
16:53:04.924678 IP 192.168.1.17.54548 > humax.50001: F 167:167(0) ack 134 win 245
16:53:04.925940 IP 192.168.1.17.9010 > humax.52127: P 1:244(243) ack 463 win 245
16:53:04.935217 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 87
16:53:04.935665 IP 192.168.1.17.54549 > humax.50001: S 906898011:906898011(0) win 14600 <mss 1460,sackOK,timestamp 84625[|tcp]>
16:53:04.936251 IP 192.168.1.17.54549 > humax.50001: . ack 4180623542 win 229
16:53:04.936832 IP 192.168.1.17.54549 > humax.50001: P 0:366(366) ack 1 win 229
16:53:04.937245 IP 192.168.1.17.54549 > humax.50001: . ack 16 win 229
16:53:04.938250 IP 192.168.1.17.54549 > humax.50001: . ack 44 win 229
16:53:04.939552 IP 192.168.1.17.54549 > humax.50001: . ack 115 win 229
16:53:04.940018 IP 192.168.1.17.54549 > humax.50001: F 366:366(0) ack 115 win 229
16:53:04.940113 IP 192.168.1.17.54550 > humax.50001: S 3719861329:3719861329(0) win 14600 <mss 1460,sackOK,timestamp 84628[|tcp]>
16:53:04.940166 IP 192.168.1.17.54550 > humax.50001: . ack 4177153166 win 229
16:53:04.940940 IP 192.168.1.17.54550 > humax.50001: P 0:475(475) ack 1 win 229
16:53:04.941168 IP 192.168.1.17.54550 > humax.50001: P 475:776(301) ack 1 win 229
16:53:04.941669 IP 192.168.1.17.54549 > humax.50001: . ack 116 win 229
16:53:04.942234 IP 192.168.1.17.9010 > humax.52127: F 244:244(0) ack 464 win 245
16:53:04.942426 IP 192.168.1.17.54551 > humax.50001: S 4286911232:4286911232(0) win 14600 <mss 1460,sackOK,timestamp 84632[|tcp]>
16:53:04.944240 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 129
16:53:04.964457 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 127
16:53:04.976106 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 117
16:53:04.978105 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 87
16:53:04.994435 IP 192.168.1.17.54554 > humax.50001: S 1422043387:1422043387(0) win 14600 <mss 1460,sackOK,timestamp 84654[|tcp]>
16:53:04.995860 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 129
16:53:04.996943 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 127
16:53:04.997698 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 117
16:53:04.998429 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 87
16:53:05.000069 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.007279 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.009487 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.010054 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.014867 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.015087 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.015151 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.015200 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.016867 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.017009 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.018273 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.018395 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0[|domain]
16:53:05.019633 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0 [1n][|domain]
16:53:05.020315 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0 [1n][|domain]
16:53:05.020384 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0 [1n][|domain]
16:53:05.022300 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0*- [0q] 1/0/0 (46)
16:53:05.024241 IP 192.168.1.17.5353 > 224.0.0.251.5353:  0*- [0q] 1/0/0 (46)
16:53:05.024511 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 129
16:53:05.024565 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 127
16:53:05.026605 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 117
16:53:05.026776 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 87
16:53:05.026940 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 129
16:53:05.027446 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 127
16:53:05.029166 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 117
16:53:05.029274 IP 192.168.1.17.1030 > 239.255.255.250.1900: UDP, length 87
Connection closed by foreign host

The only problem now is how to address this. The recommended fix is to add routes to block devices running Twonky from seeing the Humax. But this fails on a couple of fronts. Due to DHCP, the IP assigned to my tablet one day, may be assigned to my Mac another day. And secondly, I may want to access my Humax by the web interface from a device with Twonky installed. Ideally I would block DLNA ports from the DHCP range at the HDR T2 end. Even better, Humax the company, would fix their DLNA server.

Thanks again,

Jonathan.
 
Problem 1 isn't a problem: for various reasons we needed folders that can be excluded from automatic processing, and the chosen convention is to prefix such folder names with "[".
 
The problem is the file /mod/var/mongoose/html/browse/decrypt/execute.jim. The glob in the for loop

foreach f [glob -nocomplain "${base}.*"] {


doesn't match any files, if there are [] in $base, and therefore the .ts file isn't moved to the _original so the next rename of the .ts.decrypted file fails.


Thanks - that will be fixed in the next version of the webif package. The automatic decryption processes aren't affected by this bug.

Problem 2

As predicted, it appears Twonky Beam was running on the network.
The only problem now is how to address this. The recommended fix is to add routes to block devices running Twonky from seeing the Humax. But this fails on a couple of fronts. Due to DHCP, the IP assigned to my tablet one day, may be assigned to my Mac another day. And secondly, I may want to access my Humax by the web interface from a device with Twonky installed. Ideally I would block DLNA ports from the DHCP range at the HDR T2 end. Even better, Humax the company, would fix their DLNA server.

I'm experimenting with a custom kernel which has netfilter (ip tables) built in. It is based on the last kernel source which was released by Humax, which isn't the one that is used for the later firmware versions. However, it could be used to solve your problem.
 
Problem 1 isn't a problem: for various reasons we needed folders that can be excluded from automatic processing, and the chosen convention is to prefix such folder names with "[".
Hi,

I have to disagree. This bug will affect any file or folder name containing Jimsh regex special chars. I haven't tested it, but I think you will find exactly the same problem if you try to decrypt files in a folder called 'Films [kids]' or 'Films {B&W}'. The recording will decrypt, but the final rename will fail. I don't need to decrypt my '[Films]' folder but was using it to test the DLNA code.

Happy I see that af123 has picked up on this, and has promised a fix. Many thanks!

Jonathan.
 
Problem 1 isn't a problem: for various reasons we needed folders that can be excluded from automatic processing, and the chosen convention is to prefix such folder names with "[".
The [] special handling is only applicable to automatic processing. The interface should allow you to decrypt things manually wherever they are and there is a bug in the code. The problem is that square brackets are special characters in a glob string - I shouldn't be using glob here, must have missed it when I converted other code a while back.
 
Fair enough. My post is still a statement of fact, even if inapplicable in this case (I glazed over when I got to the code).
 
I'm having exactly the same problem as in the first post and it coincides with me connecting a NAS to my LAN (WD MyCloud). Will try and sort later.
 
Back
Top