I assume you had success with TwinRip and the 8000T?
Could you give a directly link to your 'results' thread on yahoo groups. I can't seem to find it and YG is not easy to negotiate (it doesn't have search by members for starters...)
T
I assume you had success with TwinRip and the 8000T?
A definite NO success to that! There turned out to be 16 bytes of the mpeg data that were 'corrupted' in every frame. With no obvious solution to this 'corruption' I gave up on the 8000T.
See message Nos 278 & 302 on the group, and some others around Dec 2004 & Feb 2005.
Get hold of 'hdf2raw.exe' and use that on the D/L'd FW:
hdf2raw pgxtf10004_all.hdf
That'll produce some .raw files, the larger of these is the uncompressed FW
It'll view in a mips dis-assembler as big-endian with a starting address at 0x9FC00000.
We can take this rather 'low-level' discussion onto that board if you're interested since this is more of a user forum, that way we may get some help from the guys who have been playing with Humax boxes for some time now.
BTW I've just got a 2nd 9200T...to play with :cool:
I upgraded the 9200T's Seagate 160Gb 'ACE' hard disk to a Seagate 250Gb Barracuda 7200.9, last night.
I wonder if you could give the complete ref for the hard drive you used as there seems to be more than one Seagate hard drive that uses this ref for example is it a Sata drive or Pata type ect.
many thanks for any info.
Hello phew could you please give me a direct link to the eLinker source code? Is it the 2.0 version or 2.1? (2.1 would be better since it will have codes to deal with the 'video' partition of the HDD).
Thanks
Just to confirm, the upgraded Hummy was left on all last night (on Sky Sports News) and all was fine this morning...
If you would be interested in collaborating on this, im keen to get a Mac Os X version up and running, I have 20 years C++ experience, so im willing to tackle this.
This is a great offer. I have looked at Humax Zone but their website leave my eyes watering (and my ears ringing of the Manic Miner music) due to the colour scheme but could not find it - however, I've got the source code now from another source...
andro101010 is working on a Mac version of eLinker too - he is working out the USB communication at the mo'.
The problem with the eLinker source code at the moment, because it is version 2.0, is that there is no code to access and transfer programmes from the 'd2' drive. This 'd2' is the video section, and was not accessible from earlier version of eLinker (written for the 8000T) and is only in version 2.1 (for the 9200T).
Unless you are able to 'decompile' the 2.1 version of eLinker and compare it against the 2.0 version and obtain some form of useable (developer) code we are stuck - unless we can get our hands on the source of the 2.1 version.
Unless I am mistaken - as I have not had time to fully examine the 2.0 eLinker code yet.
You only need to catch the message it sends to change partitions on the 9200, should be possible with a USB sniffer. The packet format's all there in eLinker source.
The problem with the eLinker source code at the moment, because it is version 2.0, is that there is no code to access and transfer programmes from the 'd2' drive. This 'd2' is the video section, and was not accessible from earlier version of eLinker (written for the 8000T) and is only in version 2.1 (for the 9200T).
eLinker version 2.0 does have the capacity to access and transfer programmes from the 'd2' drive.
eLinker version 2.0 does have the capacity to access and transfer programmes from the 'd2' drive.
Are you sure? If so thanks for the information. There has been serveral posts from users who could not access the video partition ('d2') asking for help - then finding out they did not have the latest eLinker software. Once upgraded to 2.1 they could...
Any idea what the difference is between 2.0 and 2.1?
Are you sure? If so thanks for the information. There has been serveral posts from users who could not access the video partition ('d2') asking for help - then finding out they did not have the latest eLinker software. Once upgraded to 2.1 they could...
Any idea what the difference is between 2.0 and 2.1?
Positive. I've been using version 2.0 since Nov. Tried to upgrade to 2.1 but it won't install for some reason. Don't know what the difference between the two versions is. I don't suppose that 2.1 is any more reliable! 2.0 works ok on the whole though the connection drops out fairly frequently.
I had terrible problems with drop outs until I upgraded my USB ports now working without a hitch. I had to uninstall elinker 2.0 but found it is absolutely rubbish at unintalling. I read on the hummy forum that you need to remove entries in system folders and registry and was able to install elinker 2.1. Before you ask I cant remember what parts on the system you have to manually remove but its all in the the hummy.org web site.
Thinking about it I dont know if it was my flaky USB ports or the old version of elinker that was the problem because I changed both and now working great. But I read that elinker 2.0 was meant to be for a sattelite 9100 PVR, and that elinker 2.1 was written/released in the summer of 2005 so I think that was done because of the 9200 PVR.
I have successfully downgraded the HDD in the 9200T with a Fujitsu 15Gb drive (MPF3153AT).
Look at this screenshot: http://roo.st-andrews.ac.uk/humax/15Gb.jpg and tell me where some of the '15Gb' has gone? The box reports only 9.7Gb in total, and 8Gb is reserved for JPEGs/MP3s so it doesn't leave me with a lot to record with!!!
During the process of doing so I encountered several problems which were due to the replacement of the IDE cable (and/or possibily the power cable too).
It is not recommended that a longer PC IDE cable is used instead of the very short one that originally is in the box as this causes (a) the HDD not being able to be detected, (b) the Hummy asking you if you want to format the HDD even though it is formatted already, and (c) the lost of quality recording of programmes.
You only need to catch the message it sends to change partitions on the 9200, should be possible with a USB sniffer. The packet format's all there in eLinker source.
I've done some digging and i have found out the following
1. The Humax Windows device drivers are based upon an open source driver libary called libusb (libusb.sourceforge.net), The ELinker app has a class in it called CHumaxUsbCom that wraps this interface, and handles all interactions with the device, libusb supports mac Os x and linux, and i have managed to compile and install it on my Mac. All of the data structures and function calls in the Humax code map directly onto the libusb code.
2. I am now looking at compiling a version of this class against the open source lib, rather than the Humax usb lib. and see if I can get it to access the 9200T. The lib has a test command called testlibusb which when compiled in verbose mode successfully lists information about usb devices including the 9200T.
3. Once I have this class working which encapsulates the communications protocol etc, I will try and get a simple commandline tool working that does the comms etc, in a simular fashion to the ftp client that is found on most systems. I may actualy use the source of an existing Ftp client to do this, so that it is exactly the same.
4. Ultimatly I want to take a copy of the Darwin (mac os x) webdavfs file system driver source (www.opendarwin.org) and hook it up to this class to produce a Mac OS x filesystem driver that can mount a 9200T as a file system.
Caveats are:
This will only work on unix like OS's such as Mac Os X, linux and Freebsd, im only interested in BSD and OSX personaly. However given that the original Humax windows Usb drivers are libusb compatable it would be possible to compile against them.
I have found the place in the eLinker source where Humax commented out the handler that is called if an error in the transfer is detected, but since the commented out code only stops the transfer at that point, i dont give much hope to making it more reliable. There does not seem to be any way to restart or resend the effected block.
I have a day job, so dont expect anything soon. :-(
There does not seem to be any way to restart or resend the effected block.
Ay, there's the rub!
While a Macunix version of elinker would be nice the reliability thing can only be solved when the code at the other end, inside the 9200 is also changed to implement a more robust protocol.
It is all to do with the limitations/implementation of the EMMA2 chip set. This is used both in the Hummy and the Toppy and both are USB bound to Full-speed.
Comments
I assume you had success with TwinRip and the 8000T?
Could you give a directly link to your 'results' thread on yahoo groups. I can't seem to find it and YG is not easy to negotiate (it doesn't have search by members for starters...)
Thanks again.
A definite NO success to that! There turned out to be 16 bytes of the mpeg data that were 'corrupted' in every frame. With no obvious solution to this 'corruption' I gave up on the 8000T.
See message Nos 278 & 302 on the group, and some others around Dec 2004 & Feb 2005.
How did you 'decompile' or 'decompress' the firmware for examination?
(BTW, I tried entering the post numbers to directly jump to them and I get a Python error!)
Go to the 'First' page and use 'Next>' about 5/6 times.
Re. De-compressing:
Goto http://humax.roliaforum.com for more tools and info.
Get hold of 'hdf2raw.exe' and use that on the D/L'd FW:
hdf2raw pgxtf10004_all.hdf
That'll produce some .raw files, the larger of these is the uncompressed FW
It'll view in a mips dis-assembler as big-endian with a starting address at 0x9FC00000.
We can take this rather 'low-level' discussion onto that board if you're interested since this is more of a user forum, that way we may get some help from the guys who have been playing with Humax boxes for some time now.
BTW I've just got a 2nd 9200T...to play with :cool:
I wonder if you could give the complete ref for the hard drive you used as there seems to be more than one Seagate hard drive that uses this ref for example is it a Sata drive or Pata type ect.
many thanks for any info.
Seagate Barracuda 7200.8 250Gb
Ultra ATA, Model ST3250823A
(Yes, its 7200.8 - not 7200.9 in the first post - got this disk in my hands at the moment. I got it from Aria.co.uk at £53.97 ex, £63.41 inc)
Thanks for your work on this son_t, it's all quite interesting!
Neil
Son_t the 2.0 elinker sources are on http://www.humax-zone.tv/index.php?page=development
If you would be interested in collaborating on this, im keen to get a Mac Os X version up and running, I have 20 years C++ experience, so im willing to tackle this.
andro101010 is working on a Mac version of eLinker too - he is working out the USB communication at the mo'.
The problem with the eLinker source code at the moment, because it is version 2.0, is that there is no code to access and transfer programmes from the 'd2' drive. This 'd2' is the video section, and was not accessible from earlier version of eLinker (written for the 8000T) and is only in version 2.1 (for the 9200T).
Unless you are able to 'decompile' the 2.1 version of eLinker and compare it against the 2.0 version and obtain some form of useable (developer) code we are stuck - unless we can get our hands on the source of the 2.1 version.
Unless I am mistaken - as I have not had time to fully examine the 2.0 eLinker code yet.
eLinker version 2.0 does have the capacity to access and transfer programmes from the 'd2' drive.
Are you sure? If so thanks for the information. There has been serveral posts from users who could not access the video partition ('d2') asking for help - then finding out they did not have the latest eLinker software. Once upgraded to 2.1 they could...
Any idea what the difference is between 2.0 and 2.1?
Thinking about it I dont know if it was my flaky USB ports or the old version of elinker that was the problem because I changed both and now working great. But I read that elinker 2.0 was meant to be for a sattelite 9100 PVR, and that elinker 2.1 was written/released in the summer of 2005 so I think that was done because of the 9200 PVR.
I have successfully downgraded the HDD in the 9200T with a Fujitsu 15Gb drive (MPF3153AT).
Look at this screenshot: http://roo.st-andrews.ac.uk/humax/15Gb.jpg and tell me where some of the '15Gb' has gone? The box reports only 9.7Gb in total, and 8Gb is reserved for JPEGs/MP3s so it doesn't leave me with a lot to record with!!!
During the process of doing so I encountered several problems which were due to the replacement of the IDE cable (and/or possibily the power cable too).
It is not recommended that a longer PC IDE cable is used instead of the very short one that originally is in the box as this causes (a) the HDD not being able to be detected, (b) the Hummy asking you if you want to format the HDD even though it is formatted already, and (c) the lost of quality recording of programmes.
So why have I downgraded my HDD? Read this thread for further details: http://forum.digitalspy.co.uk/board/showthread.php?t=373680
I've done some digging and i have found out the following
1. The Humax Windows device drivers are based upon an open source driver libary called libusb (libusb.sourceforge.net), The ELinker app has a class in it called CHumaxUsbCom that wraps this interface, and handles all interactions with the device, libusb supports mac Os x and linux, and i have managed to compile and install it on my Mac. All of the data structures and function calls in the Humax code map directly onto the libusb code.
2. I am now looking at compiling a version of this class against the open source lib, rather than the Humax usb lib. and see if I can get it to access the 9200T. The lib has a test command called testlibusb which when compiled in verbose mode successfully lists information about usb devices including the 9200T.
3. Once I have this class working which encapsulates the communications protocol etc, I will try and get a simple commandline tool working that does the comms etc, in a simular fashion to the ftp client that is found on most systems. I may actualy use the source of an existing Ftp client to do this, so that it is exactly the same.
4. Ultimatly I want to take a copy of the Darwin (mac os x) webdavfs file system driver source (www.opendarwin.org) and hook it up to this class to produce a Mac OS x filesystem driver that can mount a 9200T as a file system.
Caveats are:
This will only work on unix like OS's such as Mac Os X, linux and Freebsd, im only interested in BSD and OSX personaly. However given that the original Humax windows Usb drivers are libusb compatable it would be possible to compile against them.
I have found the place in the eLinker source where Humax commented out the handler that is called if an error in the transfer is detected, but since the commented out code only stops the transfer at that point, i dont give much hope to making it more reliable. There does not seem to be any way to restart or resend the effected block.
I have a day job, so dont expect anything soon. :-(
While a Macunix version of elinker would be nice the reliability thing can only be solved when the code at the other end, inside the 9200 is also changed to implement a more robust protocol.
Cliff
This beats even Microsoft and that is saying something!
I have been using the Seagate 250Gb in the 9200T for about a week now (but with lighter than normal usage...) and it has been fine.
I believe I will not have any problems using an alternative HDD in the box with the new imminent firmware update...
I will let the box do this OTA this time and will let you know how this gets on...
It's a Philips / NXP ISP1581