Is it (should it be) possible to load dongle.bin before vdr is available?

[ekluba]

Hi alltogether.

Is it possible to load dongle.bin before vdr is running? I have tried google, searched the topics here and vdr-portal but didn't find a solution.

The scenario is as follows:

My local LAN has a central 7x24 server running DHCP and DNS services. To save power this Server runs on a nslu2. My VDR runs on Dell Optiplex GX200. It is started by wake-on-lan from the dhcpd on nslu2 whenever a MediaMVP requests a lease from the DHCP server.

Since it takes a few minutes for VDR to boot, MediaMVP fails to locate the vdr and prompts the user to start a new scan. For me this is not a big problem. But visitors, guests and - that's of course the real problem - my wife don't like it.

Of course there are several workarounds. As always. For the moment i am just adding a MediaMVP to each TV in the household. This means using the existing set top box for live tv and using the MediaMVP to set timers and play recordings.

It would be better to use the streaming client to do all of it. This means: MediaMVP should load the dongle.bin from the nslu2 while VDR is already booting. The loaded dongle.bin then should be able to connect to the VDR as soon at it comes up. Keeping the user informed what is going on.


Any ideas?

TIA.
ekluba.


A short description of my LAN for you information:

- VDR and vdr-vompserver-plugin are running on Dell Optiplex gx200.
- vomp-client runs on MediaMVP H4.
- DHCP and DNS run on nslu2
- DSL is done by fritz!box fon 5140 (with DHCP disabled)

[Chris]

Hi, I think this might be possible, depending on how complicated you want to get with your NSLU2 system. From reading your post (and adding in my rusty memory of the Hx boot process), your MVP is needing a response from the mvprelay program. (Part of MVPMC). This is built into vompserver plugin, but as that is not up when you want it to be, I would recommend looking at compiling and running mvprelay for your NSLU2, if that is possible.

Once a Hx has a response from mvprelay, as far as I remember, it will sit there indefinitely trying to download its tftp image, which will happen when your main VDR box is ready.

[ekluba]

Hi Chris,

thank you for the immediate response. Mvprelay may well solve the problem. Compilation is no problem. There is a fully usable debian on the nslu2. I will try it within the next days and post the result.

ekluba.

[ekluba]

Hi alltogether.

Mvprelay was compiled and startet on nslu2 as described in http://mvpmc.wikispaces.com/mvprelay. It works exactly as described by Chris. Problem solved.

This way it is a lot more comfortable. You just start mediamvp and leave it alone until the menu appears.

So for now i will concentrate on speeding up the boot process of my vdr machine. Although it seems to me having  the tftp part of vompserver as a separate server (machine) would enhance flexibility and gain more speed. Since i am planning to join the development this might be a good thing to start.

Thank you.

ekluba.

[svalavuo]

I'm not sure if this should happen, but my MVP does WOL for my VDR.
So even if my VDR is shut down, my MVP starts it.

[Chris]

ekluba: You could quite easily have your dhcp server on your nslu2 tell the mvp that its next-server is the nslu2 and then run a tftp server on it (debian package: tftp-hpa). Then more of your mvp boot process will be done in parallel with the vdr boot process and you should be able to have vomp booted and searching for the vdr server before vdr is ready.

[avvdr]

I have a quite similar setup with a ds101j acting as dhcp server (with optware packages).
Here is the setup I use (always nfs rooted dongle - but alos works for normal of course).
NSLU2 should be very similar.
(/opt)/etc/dhcpd.conf
....

Code Select Expand

#mvp
group {
  option routers 10.222.10.11;
  option subnet-mask              255.255.255.0;
  option domain-name-servers      10.222.10.11;
  next-server 10.222.10.12;          # IP address of your TFTP server
  allow bootp;

  host mvp { # NOTE: Change the hardware ethernet to the MAC address of your actual MVP
            hardware ethernet 00:0d:fe:00:78:e6;
            fixed-address 10.222.10.60;
# the next 2 lines for NFS - devenv
            filename "vomp-dongle-nfsroot";
            option root-path "10.222.10.12:/volume1/Andreas/vomptest";
# the next line for final dongle
#           filename "vomp-dongle";
######## the next must pot. be enabled if the nfs-root dongle does not boot
#        after starting once this dongle it should work again!
#            filename "dongle.bin.mvpmc";
#            option root-path "/home/mvp,rsize=4096,wsize=4096,nolock";
            }
}



using atftpd....

Code Select Expand

/opt/etc/xinetd.d/atftp
#
# atftp
#
service tftp
{
       flags            = REUSE
       socket_type      = dgram
       protocol         = udp
       instances        = 30
       wait             = yes
       user             = root
       server           = /opt/sbin/atftpd
       server_args      = /opt/tftpboot --group nobody
       log_on_success   = HOST PID
       log_on_failure   = HOST
       disable          = no
}


and finaly the directory with the dongles:
/opt/tftpboot
- all the dongles there with the names like above.
So the dongle boots and tries to contact a server (forever) - voila
Remark:
The /opt in front coming from the optware setup - if you are running native debian it's without /opt I guess.
Regards
Andreas

[ekluba]

Chris, avvdr,

thanks a lot to both of you. That is exactly what i have tried to achieve. Glad to here it will work. I will try this perhaps next week. Special thanks to avvdr for posting you configuration. This will help a lot. I will post if it works (or if i need more help )

Have fun.
ekluba.

[ekluba]

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

I have a quite similar setup with a ds101j acting as dhcp server (with optware packages).
Here is the setup I use (always nfs rooted dongle - but alos works for normal of course).
NSLU2 should be very similar.
(/opt)/etc/dhcpd.conf
....

Hi Andreas.
The forum software ist right. This topic was indeed asleep for more than 120 days... A year has passed since. During this time my vdr/vomp/mvp configuration worked without any failures. Something else came in. An old IBM Thinkpad replaced the nslu2. A lot more cpu, mem, storage and only 2 Watts more power consumption.

During this activities I remembered my promise here to try to load the dongle.bin from the server instead from vdr. So i tried this along the guideline of your posting.
Meanwhile I can invoke tftp from any other client and get dongle.bin. Works. But my mvp's are not impressed at all. A tcpdump shows an mvp get's it's ip from dhcp3-server. But after this it sends a broadcast on port 16881. I assume it searches it's server.

Hm. All my mvp's are revision H4. What are your's? Can you tell me? And perhaps post a tcpdump of the booting process?

TIA
ekluba.



Anyway. If you read this you might be able to help me. So please have a look.

Hi again.

Problem solved by adding mvprelay to the server.

This means that all information on booting (like bootp, booting, file-name, next-server) in dhcpd.conf is meaningless to the mvp startup process.  Everything worked well with these options removed from dhcpd.conf (and after restarting dhcpd3-server) and with mvprelay, bootp and tftp set to "no" in vomp.conf.

It seems to me many people have to spend too much time to find out what is going on during mvp's startup process. It would be good to have a description in a central place....

Thank's to all of you.
ekluba.

[dingo35]

Sorry to reply this late, but since TS kicked the thread recently....

I have a setup which is comparable to TS, but I have never had the MVPmedia client prompt for a new scan.

Perhaps shortening the boot process of your VDR-server is possible: take a look at PINIT, it is an optimized version of INIT, which parallellizes the execution of the init-scripts, therefore shortening boot time dramatically. It is not very new, I believe most distributions support it out of the box for a year or so, but upgrading from an old installation does not always install pinit, or installs it in such a conservative way that a lot of dependencies between your init-scripts are assumed, just to be safe.

If you are already using pinit, perhaps one or more unnecessary dependencies in your init-scripts cause unnecessary waiting times...