• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

What we Know so Far . . .

I should probably have added that I'm a linux user, not windows, so ext3 presents no problems for me. I'm running Slackware64 14.0, using gFTP to log in to the Humax, and Okteta (KDE's native hex editor) to edit the hmt file.

Some of the cheaper channels reduce the bandwidth requirement by reducing the horizontal resolution - typically to 544x576 - which gives a file size of about 1 GB per hour. A HiDef prog recorded off ITV came in at 4.5 GB for a two hour drama - less than I was expecting for one of their prestige shows! The 1GB file took ten minutes to transfer, both to a pen drive and a HDD, so the pen drive is not the limiting factor. The 4.5GB file took 45 minutes to transfer.

Although the HD file appeared to be h264 video and AAC audio, the audio file descriptor made ffmpeg bork when trying to put it into an mp4 container without recoding. I should have tried Matroska, that would probably have worked OK. However, Avidemux worked perfectly, copying the files without complaint into an mp4 container. Playing the ts file in mplayer produced a way-out-of lip-sync viewing experience, but copying it with Avidemux (recommend 2.6.x version!) into an mp4 sorted this.

Any non-linux users wanting a quick way of formatting and manipulating ext3 files could do worse than look at SystemRescueCD (can't post a link yet, but Google will find it). Although intended for system repair duties, this is a comprehensive operating system in its own right. It can be burned to CD or memory stick, can be told to run entirely in RAM, comes complete with gParted (partition editor and disk formatter - to any FS!), file manipulation, FTP client and a web browser. And its VERY fast! A very useful little tool.

--
Pete
"Duct tape is like the Force: It has a light side and a dark side, and it binds the Universe together!"
 
I've just tried a 1TB HDD fat32 and that did take over 10 minutes for 1 GB. Off to work now but will dig out some other external memory devices later this weekend and compare - and try and find the one that was 12GB an hour or eat my hat if I don't.

I am also tempted to buy a 2000T tonight just to satisfy my curiosity about the remote and bookmarking, (see #158). I may end up disposing of it as I doubt that the Audio Description drop outs have been fixed as the drop outs are still there in the HDR-FOX's 1.03.06.
 
This all sounds very similar to HDR-FOX, except the transfer speed (see my notes in the Trail Guide). I wonder if it is deliberately crippled? I can't explain Luke's apparently slow transfer though.
 
I should have added a thanks to Black Hole for the link to the Trail Guide - I hadn't seen that before! BTW, the link is slightly broken - it has a couple of spurious inverted commas at the end!

Cheers,
 
Peter Christy said:
I should have added a thanks to Black Hole for the link to the Trail Guide - I hadn't seen that before! BTW, the link is slightly broken - it has a couple of spurious inverted commas at the end!
Click to expand...
I have fixed the link, the URL should have been between the speech marks. The same link also appears in my signature panel below (for the unobservant).

There's nothing stopping you going back to the relevant post and adding your thanks in the form of a "like".
 
Luke said:
I've just tried a 1TB HDD fat32 and that did take over 10 minutes for 1 GB.
Click to expand...
I am not having a good day and so please be gentle with me.
Turns out that it was 2.66GB file I transferred and not a very similarly named file.

On the HDR-FOX (1.02.20) with a fat32 HDD this evening it was 13GB an hour.
With an ext3 HDD 10GB an hour, (formatted by an HD-FOX).

With a USB PD fat32 it was 13GB an hour i.e. on a par with the HDD.
With a noticeably fast USB PD ext3 (yes ext3!) it was 10% slower than the ext3 HDD.

All of those 4 measurements are based on one 2.66GB unencrypted recording, 1 transfer and the HDR-FOX being placed into active standby after each copy request was initiated.

When the transfer was repeated for the USB PD fat32 it was 5% slower than before but the HDR-FOX was recording an SD and was also in chase play instead of active standby.

Now that I have more reliable measurements for the HDR-FOX I should be able to compare it to a 2000T more easily.
 
Luke said:
I am also tempted to buy a 2000T tonight just to satisfy my curiosity about the remote and bookmarking
Click to expand...
So off I went to Argos as all my local stores had a fresh delivery of 1 unit each and they brought out an HDR-FOX t2/RE.

The staff asked me what the difference was, which got me thinking.
Although the HDR-FOX will never need so much flash (as Humax couldn’t release a software version which isn’t compatible with all HDR-FOXs), it may be cheaper for both HDR-FOX and 2000T to have more than just the tuner the same and that could extend to the flash and the RAM.
 
Luke said:
Although the HDR-FOX will never need so much flash (as Humax couldn’t release a software version which isn’t compatible with all HDR-FOXs), it may be cheaper for both HDR-FOX and 2000T to have more than just the tuner the same and that could extend to the flash and the RAM.
Click to expand...

I don't understand what you mean..
 
Mass production often means cheaper costs.
Humax have brought out the 2000T.
Humax have also changed the construction of the HDR-FOX so that it has the same tuner as the 2000T. That a change has occurred is visible because of the RF in/out changing between vertically and horizontally. This is not only a change to the tuner but also a change to the back plate so it can accommodate the change.
It is therefore feasible that there are changes to the HDR-FOX brought about due to mass efficiency. As a knock on effect that could include an incidental upgrade to the flash and RAM.
 
True although they would need to retain the same flash partitioning for backwards compatibility. We have stats from an RE model running CFW that shows it has the same amount of RAM though and an identical processor to the older model.
 
The 2000t writes to a NTFS USB PD

The 2000T does not appear to have book marks. Therefore the HDR-FOX nice splice is not easily adaptable.

The 2000T transfers and decrypts SD recordings to an external drive at about 12GB an hour

The 2000T does not appear to have been tested on a 4:3 TV in the UK.

The 2000T confuses me as to when it can display the channels in the 200 range.

The 2000T '500GB' is very very quiet compared to my '1 TB' HDR-FOX.
 
Quote Luke: "The 2000t writes to a NTFS USB PD"

I would be wary of that - it depends how NTFS has been implemented. The 2000T runs a Linux operating system. The Linux kernel NTFS module reads fine, but is known to be buggy writing. Most Linux users use NTFS-3G via FUSE, which does provide reliable r/w support. I was under the impression, from reading the users handbook, that Humax use the basic kernel module, not NTFS-3G / FUSE, so you *could* end up with a corrupted NTFS partition.

I would hold off trying to write to NTFS partitions until we know how the write function has been implemented! (Anyone any ideas how to find out? We would need to get access to the operating system root, which could be dangerous.)
 
The Humax HDR-Fox T2 definitely won't write to a NTFS formatted USB hard drives without the installation of the Custom Firmware package NTFS-3g, so I guess Humax must have changed something in this area for the 2000T, maybe they have implemented NTFS-3g
 
You must log in or register to reply here.
Back
Top