News:

Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu

vomp won't boot properly - MVP hardware damage?

Started by keynet, September 28, 2007, 13:08:49

Previous topic - Next topic

keynet

Hii,

Been using vomp for a few months now, and recently compiled the mediaplayer CVS - worked first time, and really well - congratulations all round!

However, I just got a nice new 32in LCD TV (Tosh WLT66), connected an MVP to SCART 1 and now my MVP boots, shows the "connecting to VDR" screen for a second then the video output dies, but I can still telnet to it.  So I swapped for my second MVP.  That worked fine for a day, now that's doing the same.  >:(

a)  Does anyone know about possible jolts from TV's down the SCART lead that can damage the MVP - what kind of damage, can it be fixed easily?  Obviously not too bad as the bootup screen / telnet is still good.  Maybe it's the sound?

b) Is there any debug via telnet that can tell me what trouble the vomp client is having?

Thanks for any help!


rdoac

I get this every now and then, its a corrupted config file.

On one of my Vomp boxes I can just delete the config and start again as it loads everything through tftp.  The other I need a basic config file to load the firmware (as it's an H3 version)..

Edit the config and delete everything not related to BootP and Tftp and try again.

vomp-00-0D-restofmacaddress.conf

(I suppose I should say the usual about backing up etc)

keynet

Great thanks - bit of a relief!

As I couldn't see any obvious corruption in my config files, I spent some time investigating...
I have narrowed it down to an entry in the file "Power after boot"
If Power After Boot = Off,  perhaps it is doing the right thing, but in this case Off is really Off and can't be recovered ::)
Maybe the IR receiver isn't being serviced?
So a small logic bug - I'll report it to Chris via Bugzilla

Quote from: rdoac on September 28, 2007, 16:17:39
I get this every now and then, its a corrupted config file.


Chris

Fixed! It was only a problem in the cvs client and it was due to the new way that the remote module is set up.

Thanks for reporting it!

keynet

Thanks Chris.  Looks good now.
Just one minor cosmetic issue
- power up MVP in "off" state: LED is on
- turn on via remote - LED remains on
- turn off via remote - LED off. 
So LED state inconsistent at power up
We could call it a feature, but as I noticed it thought I'd tell you...!

Chris

Yeah, I think that's a permenant feature. I noticed that the first time I wrote the power at startup options. I haven't looked into it this time around, but I remember from last time that it was the very same code that turns off the led. There should be no difference in behaviour, but there is. So, anyone with a drastically over curious mind, a development environment and a couple of hours to waste, be my guest.......!