YAMU (MVP bootup failure)

[stevech]

YAMU: Yet Another MVP Uncooperating - at bootup.

Why do we still have to fight this sort of thing with the (wired) MVP? Can't Sage's people make the MVP's DHCP and TFTP code reliable like they are in Hauppauge's server software?

Here it is:
After a long battle upon purchasing, MVP finally starts running OK. Runs for months. With Sage 6.2

Today I had to reboot the Sage Server PC (XP SP2) for an unrelated reason. Been booted many times without YAMU.
MVP is now hung. Non-responsive to the IR remote. MVP was sitting idle at the time. WAF plummets.

Power-cycle MVP. "Can't get IP Address" but it goes onward anyway, fruitlessly trying to connect to the server, and spewing meaningless error messages to confuse the non-geek.

Reboot, reboot, wait. Reboot. Extended power-off. Say 3 hail Bills. Reboot. Same thing.
Power cycle switch feeding MVP. No help.
Power cycle the Linksys WRT54G that shows 127 days since a reboot.
MVP power-cycle and now it works again.

MVP now has DHCP address .100 whereas before the router reboot it was .103. Maybe unrelated.

Past experiences: Sage Tech Support responds with pablum on YAMUs

[Conejo]

Sounds like the router wasn't issuing the MVP a workable IP address via DHCP. My router allows me to assign fixed DHCP IP addresses via MAC address.

I did this because I have 'friends' who visit with their precious laptops and think their laptop problems MUST always be caused by the router at their friend's house... so when it boots back up and they fix the real problem with their laptop the router assigned them the IP that the MVP is working with.

So now I issue the MVPs special IP on DHCP.

I always believed that the Hauppauge MVP was created by some 10-year-old wizkid for a science fair project and then he started a 'company'. This 'unfounded belief' of mine would go a long way to explaining it's inner workings.

[CollinR]

put tftpd32 on your server and be done with it, you need not even do the tftp part just make it your DHCP server. It'll connect much better then.

[emveepee]

Originally Posted by Conejo

I always believed that the Hauppauge MVP was crated by some 10-year-old wizkid for a science fair project and then he started a 'company'. This 'unfounded belief' of mine would go a long way to explaining it's inner workings.

As a member of the mvpmc project I have to disagree with that comment since I think the hardware is 100% solid, although like any consumer product the odd unit will be faulty. The wired chip is a bit weak, as it is on most inexpensive media extenders, but it is certainly capable of DVD quality. I think the wireless card could have been better but in general wireless and video don't make a good mix anyway so it's difficult to point at Hauppauge.

As an example I've read about the mvp not working with Vista for a long time, and I just groan, in fact it's almost funny seeing blame being placed on some weird hardware incompatibility with Vista. With a properly installed network and functioning client and server software there is no issue.

Martin

[stevech]

Martin - just search the forums here for the many users who are IT-savvy, not making dummy mistakes, and all say the MVP works fine with the Hauppauge server software but frequently, not so with Sage, in the booting/downloading functions.

Also, while we may have your attention: The MVP's flaw where it pixel-ates on every FF is a long-overdue bug-fix.

[emveepee]

Originally Posted by stevech

Martin - just search the forums here for the many users who are IT-savvy, not making dummy mistakes, and all say the MVP works fine with the Hauppauge server software but not so with Sage.

I don't know if you are agreeing or disagreeing with me here. In any case I'm saying don't blame the mvp.

Also, while we may have your attention: The MVP's flaw where it pixel-ates on every FF is a long-overdue bug-fix.

The 2x hardware FF on the mvp is flawless as far as I can tell and I know that the Hauppauge softwware doesn't even use it. Everything else is done through software so why is it an mvp problem?

Martin

[stevech]

Originally Posted by CollinR

put tftpd32 on your server and be done with it, you need not even do the tftp part just make it your DHCP server. It'll connect much better then.

Please clarify.

and also- the DHCP server in my WRT54G (DD-WRT) router handshakes DHCP with Windows PCs just fine. Problematic with MVP and Sage's process. Hauppauge's server-side software is OK with the MVP.

[Conejo]

Originally Posted by emveepee

As a member of the mvpmc project I have to disagree with that comment since I think the hardware is 100% solid

My 'comment' was meant to be ludicrous. I know that most of the latest stuff is being envisioned by University students, not 10-year-olds, who then go out and start their own company. 10-year-olds can't get the venture capital and don't pay that well.

I've never been a fan of 'thin clients' that boot over a network, I much prefer having the App and Setting in upgradeable non-volatile memory. Yet I do believe the MVP is a brilliant piece of technology. It just doesn't deserve to take the verbal abuse I give it when we have a power outage and I have to keep the MVP unplugged for an hour in order for it to 'boot'.

[emveepee]

Originally Posted by Conejo

I have to keep the MVP unplugged for an hour in order for it to 'boot'.

To me that's another myth, although I never heard an hour before. It started with the revision H's but now that the boot sequence is known that should not be an issue. I think this particular problem is more related to problems in the tftp delivery problems.

Martin

[CollinR]

Originally Posted by stevech

MVP is now hung. Non-responsive to the IR remote. MVP was sitting idle at the time. WAF plummets.

Network dropped.

Originally Posted by stevech

Power-cycle MVP. "Can't get IP Address" but it goes onward anyway, fruitlessly trying to connect to the server, and spewing meaningless error messages to confuse the non-geek.

Reboot, reboot, wait. Reboot. Extended power-off. Say 3 hail Bills. Reboot. Same thing.
Power cycle switch feeding MVP. No help.

This is a failure of the DHCP server inside your router. Thats how you get that unable to obtain IP error, it doesn't get an IP from the SageTV or Hauppauge servers.

EDIT:
Or possibly a machine booted with a static address matching the MVPs. This would also cause the MVP to lock mentioned above.

Originally Posted by stevech

Power cycle the Linksys WRT54G that shows 127 days since a reboot.
MVP power-cycle and now it works again.

MVP now has DHCP address .100 whereas before the router reboot it was .103. Maybe unrelated.

You rebooted the router thus the DHCP server, now all is well. This was not only related but quite possibly the cause. Who is .103? A Windows box will get an IP from an MVP every time, it may fuss but the MVP will lose. This can happen by giving a local machine a static IP that is inside the DHCP pool. Might be something to look into, also firmware on the router. I know I have seen this on WRT56Gs myself.

Originally Posted by stevech

Past experiences: Sage Tech Support responds with pablum on YAMUs

food? Nice but not what you were expecting, maybe too many Geico commercials.

Next time try rebooting the router, first check and make sure your static IPs are outside the DHCP pool.

[CollinR]

Originally Posted by stevech

Please clarify.

and also- the DHCP server in my WRT54G (DD-WRT) router handshakes DHCP with Windows PCs just fine. Problematic with MVP and Sage's process. Hauppauge's server-side software is OK with the MVP.

tftpd32 is an tftp client and DHCP server, turn LAN DHCP off on your router and put the info in tftpd32 keep the router as the gateway. This way the DHCP server, tftp server and the interface server are all on the same IP.

[HawgGuy]

When I recently replaced my WRT54G, my occasional MVP hangs disappeared. I suspected they would as the cure for the MVP hangs was always to reboot the WRT54G.

[95TBird]

I also had what seemed to be random "lockups" & boot issues with my MVP that were cured by rebooting my old WRT54G. Since I have replaced it with a D-Link DIR-655, ALL of the problems have gone away...

[motobarsteward]

A small observation...

I too had the now classic tFTP Timout, tFTP Timeout, etc, Timeout Counter Expired issue. It turned out that I had changed my extender/placeshifter port to 443 some time ago to allow me to placeshift to work. I did this so long ago that I had forcotten. Setting the port back to 31099 fixed my problem. So I suggest the 'Timeout Counter Expired' message does not apply apply to the tFTP transfer but that it referes to the establisment of a TCP/UDP connection. The log could be a little more helpful in this respect. I even checked and verified this with Ethereal.

BTW, I used sage to configure my router to port forward from 443 external to 31099 internal so that I can now have my cake and eat it!