Booting problems with MVP H3 Rev 2.05

[Jö]

Hi,

I have serious problems with my new MVP H3 Rev 2.05 (wired). After a lot of try & error I found a setup, which at least let the MVP boot occasionally (needs about 10 to 20 minutes). Once booted, I can view live TV and recordings, but the MVP freezes quickly when doing some action (e.g. rewinding). When it freezed, I need to power off the MVP for at least 15 minutes until it's able to boot again ("able" means it needs again 10 to 20 minutes...).

Of course this is not what I expected from my MVP, so I hope I can find help here in this forum 

My setup is:

• Debian i386 Etch, all VDR packages from e-tobi.
• Official 0.7.2 dongle (from loggytronic.com) with a proper dongle.bin.ver generated with the dd command posted 1000 times in VDR forums
• Bootp disabled in vomp.conf: DHCP is provided by a server in my network. DHCP was never a problem.
• TFTP enabled in vomp.conf: dongle.bin and dongle.bin.ver are placed in the proper directory

These are the vompserver.log messages:

Code Select Expand

20:09:38.557622 [info]   Main - Logging started
20:09:38.558803 [debug]  UDPReplier - UDP replier started
20:09:38.558938 [info]   Main - Not starting Bootpd
20:09:38.559049 [info]   Main - TFTP path '/usr/share/vdr-plugin-vompserver/'
20:09:38.559069 [debug]  Tftpd - Starting TFTPd
20:09:38.559119 [debug]  Tftpd - TFTP server started with base path '/usr/share/vdr-plugin-vompserver/'
20:09:38.559168 [debug]  MVPRelay - MVPRelay replier started
20:09:38.559187 [info]   Main - MVPRelay started
20:09:38.559222 [debug]  Main - MVPServer run success
20:09:57.625999 [debug]  MVPRelay - MVPRelay request from 192.168.42.51
20:09:57.626102 [debug]  MVPRelay - Sending my IP as c0a82a46
20:09:59.154172 [debug]  Tftpd - Wait finished
20:09:59.154275 [debug]  TftpClient - Client handler started
20:09:59.154358 [debug]  Tftpd - Starting wait
20:09:59.154389 [debug]  TftpClient - RRQ received for dongle.bin.ver
20:09:59.154421 [info]   TftpClient - File: '/usr/share/vdr-plugin-vompserver/dongle.bin.ver'
20:09:59.156607 [debug]  Tftpd - Wait finished
20:09:59.156630 [debug]  TftpClient - Client handler started
20:09:59.156665 [debug]  Tftpd - Starting wait
20:09:59.156688 [debug]  TftpClient - RRQ received for dongle.bin
20:09:59.156709 [info]   TftpClient - File: '/usr/share/vdr-plugin-vompserver/dongle.bin'
20:10:01.355027 [debug]  TftpClient - Retransmitting buffer
20:10:01.895027 [debug]  TftpClient - Retransmitting buffer
20:10:01.895655 [ERR]    TftpClient - Client sent a data packet!
20:10:01.895677 [info]   TftpClient - processMessage terminating connection
20:10:02.455028 [debug]  TftpClient - Retransmitting buffer
20:10:03.555033 [debug]  TftpClient - Retransmitting buffer
20:10:04.655563 [debug]  TftpClient - Retransmitting buffer
20:10:05.755038 [debug]  TftpClient - Retransmitting buffer
20:10:06.855041 [debug]  TftpClient - Retransmitting buffer
20:10:06.890157 [debug]  Tftpd - Wait finished
20:10:06.890190 [debug]  TftpClient - Client handler started
20:10:06.890307 [debug]  Tftpd - Starting wait
20:10:06.890337 [debug]  TftpClient - RRQ received for dongle.bin
20:10:06.890361 [info]   TftpClient - File: '/usr/share/vdr-plugin-vompserver/dongle.bin'
20:10:07.955041 [debug]  TftpClient - Retransmitting buffer
20:10:08.019399 [debug]  TftpClient - Retransmitting buffer
20:10:09.055056 [debug]  TftpClient - Retransmitting buffer
20:10:09.119044 [debug]  TftpClient - Retransmitting buffer
20:10:10.155049 [debug]  TftpClient - Retransmitting buffer
20:10:10.155223 [debug]  TftpClient - Lost connection, exiting
20:10:10.219046 [debug]  TftpClient - Retransmitting buffer
20:10:11.319053 [debug]  TftpClient - Retransmitting buffer
20:10:11.920271 [debug]  Tftpd - Wait finished
20:10:11.920362 [debug]  TftpClient - Client handler started
20:10:11.920446 [debug]  Tftpd - Starting wait
20:10:11.920477 [debug]  TftpClient - RRQ received for dongle.bin
20:10:11.920506 [info]   TftpClient - File: '/usr/share/vdr-plugin-vompserver/dongle.bin'
20:10:12.419056 [debug]  TftpClient - Retransmitting buffer
20:10:13.059055 [debug]  TftpClient - Retransmitting buffer
20:10:13.059762 [ERR]    TftpClient - Client sent a data packet!
20:10:13.059784 [info]   TftpClient - processMessage terminating connection
20:10:13.519076 [debug]  TftpClient - Retransmitting buffer
20:10:14.619059 [debug]  TftpClient - Retransmitting buffer


Any many more of these "dongle.bin" requests.

I also tried disabling TFTP in vompserver setting up a standalone TFTP daemon. Same procedure here: dongle.bin.ver request works, the dongle.bin requests are repeated a lot of times.

Besides this my network is quite stable. To exclude hardware problem I tried different network cables including a WLAN bridge without any changes in the strange behaviour.

To exclude whether vdr-plugin-vompserver is broken in some way, I compiled libmvp and vdrmvp from CVS: it works with the builtin Hauppauge dongle, but has similar TFTP problems with a newer one. Same here: after some time transferring the file did work. But mvpvdr is no option for me: it's not internationalized, it has problems with special characters in filenames and the TV picture is quite dark and has a bad quality. So I really want to get vomp up and running

Thanks a lot for reading. I hope someone can help.

Regards,

Jö

[Chris]

I don't think you've acquired one of the better MVPs, unfortunately...

Firstly the several requests for dongle.bin - I don't see how or why this would happen. _The_ pitfall at the TFTP stage is the dongle.bin.ver file telling the MVP it doesn't need to download the dongle. You have passed that stage. With the way that your standard TFTP server does the same thing it's obviously not a vomp problem, it's a more general problem.

Secondly, power cycling the MVP takes 15-20 minutes - yes, I have this with my H3. I think this may eventually be solvable with some research into dongle.bin.ver contents, but I'm not sure. As it is, you have to leave an H3 switched off for that long to ensure that the memory loses power and therefore needs to check for a new dongle. (i.e. it does a real full boot up with empty chips, something like that).

Thirdly - performance when you actually get it going - it crashes after a while and has a dark picture. Again, I have these symptoms with my H3, which is why it now doesn't get turned on and I don't work with it any more. I don't know why it crashes, but I don't think it's a direct software fault in the vomp code because otherwise the wired-only versions would do the same thing. As for the dark picture, more bad news here. I read on the net somewhere that this was a hardware problem, but could be fixed if you happened to be an electronics guru and were willing to spend some time inside your MVP. If you have seen the dark picture on mvpvdr, (and it is the same effect that I have seen on mine), then there is virtually no chance that any other software, vomp, mvpmc, etc, would be any better. Sorry.

Sorry for not having any solutions. Maybe someone who has wrestled with the wireless MVPs more than me (not difficult) could provide some input...