Topics

Maybe this problem is similar to that described here: http://forum.loggytronic.com/index.php?topic=196.0

But its a bit different - seen from the network side.
I'am user of an vdsl-line (50000 KBIT down/10000 KBIT up !!) and so I realised access to my homenetwork via ipsec/pptp.  Ipsec does not work with vomp, ok , in that case I'am on the other side in a different subnet and maybe the same problem described above.

But if I dial in with pptp I will have an ip adress of my home network and it does also not work. I tried different configurations (pptp dial in via original XP and alternativly pptp dialin via pptp addon running on ipcop) but in both cases this result:

09:52:27.000859 [debug]  Command - processing message 25
09:52:27.000859 [debug]  Command - Sending message to boxstack
09:52:27.000875 [debug]  Command - processing message 25
09:52:27.000875 [debug]  Command - Sending message to boxstack
09:52:28.000484 [debug]  UDP - Wait for packet
09:52:28.000484 [notice] VDR - Broadcasting for server
09:52:29.000984 [debug]  UDP - Wait for packet
09:52:29.000984 [notice] VDR - Broadcasting for server

and so on in an infinite loop. Of course vompclient is running fine at home on the same machine.

Theoretically it should run fine with that kind of vdsl-line. I connected an eeepc to my homenetwork (via pptp) and was able to use vdr-streamdev-client without any problem (via internet !!), even channelswitching was relatively smart. Seems to be a problem with that broadcasting/connecting code inside the vompclient, but I can't imagine what it could be......

Schade, sehr schade ....

greetz

klaus

Would this work ?

grab vido output from /dev/dvb/adapterX/video0 and send this to the mvp (instead of  a selected channel) this stream contains also osd output (like fbtv does).
In this mode all commands frome mvp's remote-control are send directly  to the vomp-plugin, the vomp-plugin controls the vdr  like the control-plugin does. Would be a perfect  vdr client , with all features of the vdr : mp3, define recordings, create dvd all you can do with the vdr menu.

Would only work with ff-cards....

klaus

Hi all,

I read in another forum that the mvp has problems in mixed networks (falls to half-duplex) under some circumstances. With the vomp plugin/server we have observed sometimes also network problems (channel not available / cannot play recording etc).

I played a lot around that problem and I figured out that if one of the partners (the vdr or the mvp) is operating on 10 MBit/ half or full duplex, vomp does not operate properly. Please to all: Could you reproduce this behaviour ?

It's easy to test that by setting eth0 of the vdr to 10MBit mode with the tool mii-diag. The call is

mii-diag -F <val>

   -F  --fixed-speed <speed>
        Speed is one of: 100baseT4, 100baseTx, 100baseTx-FD, 100baseTx-HD,
                         10baseT, 10baseT-FD, 10baseT-HD


I tested it on two different networks, on both I could reproduce it. Thanks a lot


Klaus

I have a feature request: If the automatic shutdown feature on vdr is enabled (menu//setting/other/min. user inactivity > 0)  it will shutdown, even if a mediamvp client still is active (live-tv or recording). There are two possibilities to prevent this:

a) directly in the plugin
b) with a shutdown-hook script

a) only could be done by the develteam, solution b) is realised by scriting, but in this case the script has to detect that there are active clients. I played around something with netstat, but can't detect some usefull information.

Any idea?

Thanks

Klaus

I've got a theoretical question. Would it be possible to change the the default ports of the communication between vomp and mvp ?

Background: after the bootp session the mvp sends out an udp-broadcast on 16882 - the server answers and tells his guiserver and mediaport data. If vomp could communicate on other ports, it would be possible to run a second mvp-server on the same machine (for example mvpmc) and switch to this server by providing another dongle.bin. the vomp-plugin itself could provide such a mechanism, so we could use the best of both servers - and you don't need to implement all this features.....

greetz

klaus

hi chris,
dongle 14 works fine in an enviroment with two servers running the plugin (both vdr 1.2.6). thanks for fixing that!

Other topic - investigation of next-server entry.
I've set up the dhcp server on a third machine (running ipcop) providing the following entry to dhcpd.conf:

allow booting;
allow bootp;

........
........

group {
next-server 192.168.3.201;
    host mvp
    {
        filename "dongle.bin";
        hardware ethernet 00:0d:fe:00:23:c1;
        fixed-address 192.168.3.79;
    }
}

192.168.3.201 is the vdr where tftpd  is runnig
192.168.3.79 the mvp


works fine....


thanx a lot for your work. Your solution (already at this early state) is much more reliable and stable then other solutions for vdr, although there are only basic functions. but sometimes less is more!!

klaus