The freezing problem that I reported in my previous post, is caused by a bug in the firmware. Firmware 3.13 through to the current one 3.15. This was told to me by the MagicTV support technician who worked on my box. The bug is not in firmware 3.12
The technician informs me that he will be reporting the bug to MagicTV & says that soon, a revised firmware will be available for upgrading.
The work-around, at the moment, is that when one does a factory reset & the guided set-up launches, to accept the default 1080i screen resolution & after the channel scan is done, in step 4, to accept the settings & then go & change the screen resolution to 720p, as in my case.
A mate has bought a 3600 & it has firmware 3.12. His box does not exhibit the freezing fault.
The disk in my unit is the same as @lostKiwis: the WD5000AVVS. The RPM is not listed on the disk label nor could I find it listed in the spec sheet for the on WD's website, but various other websites rate it at 7,200rpm, which seems odd to me as I thought all "green" disks were lower rev'ing.
It definitely runs a LOT cooler than the temporary Seagate 7200rpm disk I used and I wouldn't recommend using one of those full-time - unless you add a fan to the case :)
2lostkiwis: Hi everyone. After being quiet for a long time I have made a lot of progress in creating an image that can upgrade the MTV from a USB flash drive. I have managed to modify the filesystems embedded in the upgrade file and correct the embedded checksums that otherwise prevent upgrading. This would mean that an upgrade file could be created, based on the latest v3.15 firmware that would enable fixed skip forward (1 minute) and skip backwards (8 seconds) times. Also it could enable by default the telnet server. All this without opening the cover of the unit.
But I have one last problem to solve. One of the embedded filesystems in the upgrade file, is JFFS2. JFFS2 is a compressed file system suitable for flash memory due to its wear leveling. I mounted this filesystem on a debian system and made the required modifications (enabling the telnet server and replacing a library). The problem is that the compression algorithm used in Debian appears to not be supported by the MTV - because during the upgrade process I get the following error messages to the console port:
block2mtd: mtd8: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ block2mtd: mtd8: [d: /dev/loop0] removed block2mtd: mtd8: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ JFFS2 compression type 0x07 not available. Error: jffs2_decompress returned -5 … repeated lots of times block2mtd: mtd8: [d: /dev/loop0] removed Restarting system. So the only remaining problem is to find a way to modify the JFFS2 image on a linux system in a way that is compatible with the MTV kernel/software. If anyone has suggestions, I'd be happy to hear from them.
Cheers, Ian.
p.s. I also came as close as I ever had to bricking my MTV. That was pretty scary... especially telling my wife :-)
Sorry I can't help. But just saying well done and keep up the great work. There would be many people who appreciate this.
2lostkiwis: But I have one last problem to solve. One of the embedded filesystems in the upgrade file, is JFFS2. JFFS2 is a compressed file system suitable for flash memory due to its wear leveling. I mounted this filesystem on a debian system and made the required modifications (enabling the telnet server and replacing a library). The problem is that the compression algorithm used in Debian appears to not be supported by the MTV - because during the upgrade process I get the following error messages to the console port:
block2mtd: mtd8: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ block2mtd: mtd8: [d: /dev/loop0] removed block2mtd: mtd8: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ JFFS2 compression type 0x07 not available. Error: jffs2_decompress returned -5 … repeated lots of times block2mtd: mtd8: [d: /dev/loop0] removed Restarting system.
Okay, I have solved that problem. The linux distribution I was using had LZO compression support in the JFFS2 driver - which was not compatible with the MagicTV. I recompiled the JFFS2 kernel module without LZO support and regenerated the upgrade files. So the changes I made, were to enable the telnet server and modify the libdfmgr.so library to skip forward 1 minute and skip back 8 seconds.
I have tested the upgrade file on my MagicTV and the previous errors are gone, the upgrade completed successfully. My MagicTV was already on 3.15NZ so I wanted to try a few more. I upgraded my parents that was on 3.14NZ and also my next door neighbors that was also on 3.14NZ - both went without a hitch.
So I really think I'm done now, but there is still one problem. I don't really mind giving the work away but two things worry me:
1) I don't want to be responsible for anyone that bricks their MagicTV. I am very confident that there are no problems left, but it's the law of averages that something unrelated could go wrong during an upgrade - and I don't want to be blamed for that. Basically I would only give it away if people are completely aware that they use it at their own risk. It would probably void your warranty as well - if the distributor starts checking for it. Still a downgrade back to the standard 3.15NZ is completely possibly - then it would be very hard to tell.
2) I am not sure I can distribute the upgrade files, because MagicTV probably have some copyright on some of the files in the image. Now they haven't exactly complied with the GPL - they don't even distribute their patches for GPL software used, which is pretty slack. But I can't play that game because they probably have more money for lawyers than I do. So perhaps I could distribute some diffs and software to build the image using the upgrade package downloaded from them.
2lostkiwis: But I have one last problem to solve. One of the embedded filesystems in the upgrade file, is JFFS2. JFFS2 is a compressed file system suitable for flash memory due to its wear leveling. I mounted this filesystem on a debian system and made the required modifications (enabling the telnet server and replacing a library). The problem is that the compression algorithm used in Debian appears to not be supported by the MTV - because during the upgrade process I get the following error messages to the console port:
block2mtd: mtd8: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ block2mtd: mtd8: [d: /dev/loop0] removed block2mtd: mtd8: [d: /dev/loop0] erase_size = 128KiB [131072] block2mtd: version $Revision: 1.30 $ JFFS2 compression type 0x07 not available. Error: jffs2_decompress returned -5 … repeated lots of times block2mtd: mtd8: [d: /dev/loop0] removed Restarting system.
Okay, I have solved that problem. The linux distribution I was using had LZO compression support in the JFFS2 driver - which was not compatible with the MagicTV. I recompiled the JFFS2 kernel module without LZO support and regenerated the upgrade files. So the changes I made, were to enable the telnet server and modify the libdfmgr.so library to skip forward 1 minute and skip back 8 seconds.
I have tested the upgrade file on my MagicTV and the previous errors are gone, the upgrade completed successfully. My MagicTV was already on 3.15NZ so I wanted to try a few more. I upgraded my parents that was on 3.14NZ and also my next door neighbors that was also on 3.14NZ - both went without a hitch.
So I really think I'm done now, but there is still one problem. I don't really mind giving the work away but two things worry me:
1) I don't want to be responsible for anyone that bricks their MagicTV. I am very confident that there are no problems left, but it's the law of averages that something unrelated could go wrong during an upgrade - and I don't want to be blamed for that. Basically I would only give it away if people are completely aware that they use it at their own risk. It would probably void your warranty as well - if the distributor starts checking for it. Still a downgrade back to the standard 3.15NZ is completely possibly - then it would be very hard to tell.
2) I am not sure I can distribute the upgrade files, because MagicTV probably have some copyright on some of the files in the image. Now they haven't exactly complied with the GPL - they don't even distribute their patches for GPL software used, which is pretty slack. But I can't play that game because they probably have more money for lawyers than I do. So perhaps I could distribute some diffs and software to build the image using the upgrade package downloaded from them.
Feedback/suggestions welcomed.
Cheers, Ian.
That's fantastic. I agree with the first point of the individual accepting full responsibility for applying any unauthorised update.
The second point is tricky. If you supplied the tools for the firmware modification, how big a download, and how complex would the process be? I think this is probably the best solution, so the end user has all the responsibility, and also can update as newer firmwares are released. And also can set what skip times they prefer?
RingoTB: Thanks to the various people who have discussed upgrading the HDD. I have done some experimenting with an old 120GB HDD. So far I have successfully changed the HDD and everything is working correctly, although of course the HDD is now smaller. I am now going to purchase a 2TB drive and install that one.
Bob123 states he runs a 2TB WD green drive, evanh just states a 1TB drive, and gpf talks about the original "green" disk when he was testing a 7200RPM Seagate drive.
My MagicTV came with a Hitachi Cinemastar P7K500 7200RPM drive.? I usually take a "green" drive to be 5400 or 5900RPM.
I am trying to decide whether to replace the original 500GB 7200 RPM drive with a 2TB 7200 RPM drive or a "green" 2TB 5900 RPM Seagate.
My question is this:?
Can people please advise what their original drive was, Make and Model, so I can compare the specs. I am leaning towards the 5900RPM drive as it should run cooler, but I want it to be fast enough to not error when recording 4 overlapping programs on 2 different channels.
The MTV doesn't overlap it's recordings per-se. It stores the overlapping period as a separate file, ie: For two consecutive programmes on the same channel you end up with three files on the HDD. That said, I have noticed that ffwd/frwd is a little more jerky when recording two programmes as well.
The 1TB replacement I used is a WD10EURS, which is from a revised lower power range of the WD5000AVVS. Further reading - http://www.geekzone.co.nz/forums.asp?forumid=83&topicid=43120&page_no=51#494173
The Hitachi Cinemastar P7K500 uses up to 7.9 watts so that's a notable amount more than the WD drives.
Both the Western Digitals and the Seagates look perfectly fine for the job. The Seagate ST2000DL003 clocking in at a fixed 5900 RPM would be the more responsive. The WD AV-GP series are dual speed I think and the power rating specs are so good I suspect they are only covering 5400 RPM.
Here's the prices for the 2TB drives: - http://www.ascent.co.nz/productspecification.aspx?ItemID=393803 and http://www.ascent.co.nz/productspecification.aspx?ItemID=392086
2lostkiwis: Okay, I have solved that problem. The linux distribution I was using had LZO compression support in the JFFS2 driver - which was not compatible with the MagicTV. I recompiled the JFFS2 kernel module without LZO support and regenerated the upgrade files.
2lostkiwis: Okay, I have solved that problem. The linux distribution I was using had LZO compression support in the JFFS2 driver - which was not compatible with the MagicTV. I recompiled the JFFS2 kernel module without LZO support and regenerated the upgrade files.
evanh: The Seagate ST2000DL003 clocking in at a fixed 5900 RPM would be the more responsive. The WD AV-GP series are dual speed I think and the power rating specs are so good I suspect they are only covering 5400 RPM.
Ah, not quite right it seems. I found this explanation - http://www.silentpcreview.com/article786-page2.html - that basically shows that WD replacing the RPM spec with the label IntelliPower is pure bullsh*t. The spindle speed is not dynamic in any way.
So, the AV-GP drives are all 5400 RPM. That's not bad though - it makes them quieter and cooler running and as long as performance is good enough, which it is, then all is fine.
Certainly I have no issue with the 2TB Green WD drive - even when going hard out ie recording 2 x HD programs and watching a 3rd HD program , the 3700 also take a USB drive to increase capacity past the single internal drive
Thanks for everyone's replies. I think I will trial a Seagate 5900 RPM 2TB drive. I have one in my media PC that I can swap out for a test at NIL cost.
I've also installed Linux on an old PC so I will hopefully be able to copy across the existing recordings to the 2TB drive.
evanh, thanks for the info on how the Magic TV saves files for 2 overlapping programs. It is a very nice feature. The Panasonic Blu-Ray Recorder (BW850) I have has to have a 1 minute break between consecutive recordings when using the same tuner.
fatjulio:That's fantastic. I agree with the first point of the individual accepting full responsibility for applying any unauthorised update.
The second point is tricky. If you supplied the tools for the firmware modification, how big a download, and how complex would the process be? I think this is probably the best solution, so the end user has all the responsibility, and also can update as newer firmwares are released. And also can set what skip times they prefer?
It's not so much supplying the tools because they are not user friendly and mainly based in linux. The other alternative is only supplying a binary patch against the official firmware which is what I have done. I have written a script that downloads the official firmware, checks it's md5sum and then applies a binary patch file that's only 17.5k big. The script then also checks the md5sum of the patched firmware. All up the script and associated utilities are 1.8M zipped up. I have also come up with a disclaimer to include. I'm not a lawyer, and I'm sure it's not water tight but I hope people get the idea. I would like to do a bit more testing before releasing it though.
RingoTB: evanh, thanks for the info on how the Magic TV saves files for 2 overlapping programs. It is a very nice feature. The Panasonic Blu-Ray Recorder (BW850) I have has to have a 1 minute break between consecutive recordings when using the same tuner.
Yeah, I may have given a slightly over-reaching idea, it only works when on the same station. Two consecutive recordings on differing stations can't coincide with a third station recording. So, it's similar to the Panasonic in this situation.
Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly
to your computer or smartphone by using a feed reader.
ID Verified
