• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

Graded stock shipping with strange filesystem format?

ChrisDaniels said:
Not heard anything on that front.. sorry.
Click to expand...
I've just had an email from Humax saying...
Repeat Downloads for the HDR-FOX T2

Model: HDR-FOX T2
Software Version: FHTCP 1.03.12
System ID: 80BC.7E00
Update Date: 07 FEB 2014 (as will appear in the System Information menu)

Release Notes
TV Portal upgrade
BBC iPlayer Version 3 (now supports subtitles)
Supports BBC News & Sports Apps (to be released March 2014)
Improved WiFi connection reliability
Improved EPG FIND results
Resolved recordings failures (using Padding) when in standby for over 8 days
Resolved BBC Three HD and Four HD recording issues
All these fantastic improvements will take place automatically if your HDR-FOX T2 is left in standby mode overnight.
The Over Air Download (OAD) has been booked for the following dates during May:

Start: 07/05/2014 @2am
End: 12/05/2014 @9am

Start: 14/05/2014 @2am
End: 16/05/2014 @9am

Start: 19/05/2014 @2am
End: 21/05/2014 @9am
Click to expand...

As I'm already running CFW based on this version (1.03.12/2.22) will my Hummy ignore it or do I need to prevent it installing it (which is easy enough, just have to remember to do so)?

And does its eventual release mean Chris can spill the beans?
 
It should not auto-update based on the version numbers, but of course with the CF installed it would be daft not to also have an anti-OTA measure in place (OTAs wipe out CF).
 
No version of 1.03.12 with or without the custom firmware added will be 'wiped' by an OTA of 1.03.12, so you don't need to do anything to protect what you have until 1.03.13 or higher is OTAed
 
Sorry to post on an old thread, but found it after experiencing problems with a Manager's Special I bought some time in 2014. Running 1.03.12 and 3.00.
It stopped recording ie. said it was, but it wasn't. Fix-disk solved the not recording problem, but re-runs still showed a massive number of errors. Checked the other hummy (same versions) and it was rock solid. Not a single error.
Changed the disk. Formatted it from the UI. Reinstalled web-if. Recorded some stuff. Ran Fix-disk, massive number of errors. Fix-disk hung. Rebooted. Humax wanted a reformat. Did that. Ran srma. Loaded Humax firmware. Didn't install CF. Did a couple of recordings. Replaced the disk with the well-checked and manually reformatted original. Checked the pulled disk which was formatted via UI, and no errors.
While still in stage 1 of this problem, I ran e2fsck on the command line and it said something to the effect that a library was out of date, and I was wondering if the problem might be some mismatch between packages when updating on a non-current version of CF.
(I'll get my coat ...)
 
Resurrecting this one...

I use a 2TB Samsung USB 3.0 M3 Portable, external USB disk. single partition. It was formatted by the Humax UI, kernel 1.03.12.

It seems to work fine on the Humax: I regularly mount it, and rsync the internal disk to it. No obvious problems.

I happened to connect it to my Linux PC and, as normal, I run fsck (-n) before attempting to mount it. Errors on just about every inode, similar to above. PC is Linux kernel 4.3, e2fsprogs 1.42.13. I did not correct any errors.

I tried mounting it anyway, read-only, on the Linux PC, and it does seem OK, despite all the fsck errors.

So, the question is: what to do?
  • just ignore it, and hope that all really is OK
    • that is what people seem to be doing, but I wonder if it's wise?
  • reformat on Humax UI
    • earlier posts suggests this won't help? possibly the cause of the problem in the first place?
  • reformat on PC, and ensure fsck clean
    • but will Humax still like it?

thanks much...
 
I would be inclined to leave well alone, as it seems to be fine on the 'Fox. There may be some difference in the details of the Humax-prepared file system and the Linux one. If you are really keen, you could analyse it from the Humax command line.
 
Black Hole said:
I would be inclined to leave well alone, as it seems to be fine on the 'Fox. There may be some difference in the details of the Humax-prepared file system and the Linux one. If you are really keen, you could analyse it from the Humax command line.
Click to expand...

Yes, I wondered...

my concern is because I also intended to use the disk on the Linux PC, as a quicker way to transfer files... but I could mount it read-only, and then it's less of a worry.

Interestingly, I checked with a friend, who has the same disk, and the same Humax: he formatted his on the Linux PC, and it works perfectly on the Humax, but passes fsck clean on the Linux PC.

that would seem to be preferable, so perhaps I'll start again....

thanks though.
 
If you are in a position to start again and format the disk using a proper Linux, I commend that as the best course of action.
 
Black Hole said:
If you are in a position to start again and format the disk using a proper Linux, I commend that as the best course of action.
Click to expand...
I agree. I'm the originator of the thread and reformatted the errant disk from the Humax command line using the custom firmware tools (which, I suspect is the same as any other Linux-based formatter) and had no problems. It seems that that version of the Humax app formats it in a strange way, but it doesn't need the strangeness. Does anyone have any idea why it does so? Simple bug or some clever scheme?
 
Thanks both, yes I wondered.

My concern is: the fsck errors do not look like random corruption, at least not in my 20 years of UNIX filesystem failures :)

Many of the errors look like: inode bits indicate features that are not globally enabled for this fs.

That makes me worry that this was in some way intentional, and Humax simply failed to update their fsck to match. Silly thing to do, of course, but...

that might be borne out by the suspicion that Humax had made fs changes to support e.g. ext3 fs use on external USB disks that are intended to be ripped out without first explicitly unmounting: remember the on-telly UI has no unmount/eject feature, right? Although af123 did add it to the WebIF when I requested it bless him.

Given that, and the fact that it is the Humax that writes to the disk, I wondered if it would be safer to leave the fs as Humax-created, and only mount it RO on other Linux boxes.

Yet all my other UNIX experience tells me otherwise: re-make the fs clean, on Linux, and that does appear to work OK on the Humax.

Yet without knowing what Humax were playing at, we might then be losing something important...?

sigh.

thanks again for the comments...
 
in summary: is it likely that Humax intentionally used a non-standard ext3 derivative, for some specific reason, and failed to ship an fsck that knew about that?

If so, what do we lose by remaking the fs off-Humax?
 
I think I'm right in thinking the e2fsck we use from the command line on the Hummy is one installed by custom firmware and no one installed by Humax? So if they did deliberately use extra features it's no surprise fsck didn't know about them.
 
Might be worth trying tune2fs -l on the Humax formatted file system and the Linux formatted file system and seeing if there are any interesting differences.
 
MartinLiddle said:
Might be worth trying tune2fs -l on the Humax formatted file system and the Linux formatted file system and seeing if there are any interesting differences.
Click to expand...

Yes, we will try that, thanks.

Ah, but perhaps I'm more confused that I realised: is the ext3 code on a system with the latest CF, is that code supplied by Humax or part of af123's replacement kernel in the CF?

If the latter, then all my talk of Humax-specific filesystem code is awry, no?
 
In case anyone is interested...

I took my external USB drive, formatted on the Humax with 1.03.12, and connected it to a Linux PC, kernel 4.3, e2fsprogs 1.42.13.

fsck failed, as usual, with the errors detailed in posts above.

I mounted it RO, then ran a find on every file in the My Video directory, and used the filenames as arguments to wc. That counts the bytes in each file - the purpose here was to ensure that we could read all the file.

The disk had 650GB of data on it, in 2,200 files. I was able to "wc" every single file, without generating any errors whatsoever, either from the kernel ext3/4 fs code, nor from userland system calls from the find and wc utils.

So, whatever is wrong/unusual about these Humax-formatted filesystems, it does not seem to affect operation on a Linux system, at least when mounted RO.

Not sure I would want to mount it RW on the Linux system though.
 
Last edited:
ABMorley said:
While we're raking over an old thread.... any chance you can divulge now? I think Humax really have dropped support now..
Click to expand...
It was because it interfered with another manufacturers box.. Despite the DTG testing it prior to release.. Nothing like what some people were saying at the time! Lol
 
Great to find out the reason. Thanks.

Now all we want to know is what's with those mystery bits in the filesystem. Ho hum!
 
You must log in or register to reply here.
Back
Top