Just installed this plugin. My MVP gets stuck at locating server. It seems to boot quite quickly but then just sits there.
Any ideas on what maybe causing this?
Thanks
zapp
At that point the MVP is UDP broadcasting on it's subnet for a VDR server running the vompserver plugin. The fact that it's not connecting means that it's not getting a reply from the vompserver plugin part of VDR. There are quite a few things that can cause this... Is vdr definitely running with -P vompserver ? Are they both on the same subnet? Is the linux box firewalling the ports required? (3024 on udp and tcp), and possibly other reasons. So what do you think, do any of these sound possible?
Hi Chris
Thanks for ypur reply.
As far as I can tell the Vomp plugin is working . It is showing on the plugins menu on VDR OSD in the setup screen.
There is no firewall active on my Linux box.
Here is a copy of my DHCP setup
allow booting;
allow bootp;
option domain-name "DOB1";
option domain-name-servers 192.168.0.254;
option subnet-mask 192.168.0.255;
option routers 192.168.0.254;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.150 192.168.0.175;
server-name "192.168.0.99";
}
host mvp {
filename "dongle.bin";
hardware ethernet 00:0D:FE:00:24:XX;
fixed-address 192.168.0.98;
}
Thanks zapp
oops spotted my own error I had the subnet mask set incorrectly.
How does Vomp know where the recordings are as mine are not being listed at the moment.
Thanks
zapp
Glad you got that one sorted, but no recordings being listed is very odd.. The client asks the vompserver plugin which in turn asks vdr directly. I have no idea what could cause that, if anyone else is reading this thread, have you ever seen anything like this?
bit of an update, not sure why it didn't work before, but recordings are now listed. However they do not play, the screen goes blank & stays that way. Also when selecting a live tv channel I get "channel not available" on screen. This is the same for all channels & even if I select the one currently being viewed by VDR.
Thanks
zapp
I also observed this, seeing the recordings and playing them shots mvp into the nirwana...
In my case the solution was to connect the mvp to the 100 MBit switch, before it was on an 10 MBit switch. The mvp-client seems to be very impatient, perhaps chris can change this behaviour a little bit.
greets
klaus
Well believe me, I'd love to fix it! But errrrr... I don't really know what's going on here. I have one suspicion which someone is testing for me (I hope), if it isn't that, then I'm lost. The shortest timeout in the client is 10 seconds I think, but that should be enough for VDR to do something and send back the results. I have no idea how moving from 10Mb to 100Mb could make any difference, unless your network is almost saturated all the time!
What version of Linux, and what version of the kernel is everyone running on the VDR server?
My kernel is
uname -r
2.4.26-ctvdrskas-1
This is a well tested kernel espacially vor v4l apps, published by a big german computer magazine (ct).
...have no idea how moving from 10Mb to 100Mb could make any difference ...
I think there is a difference. The 10 MBit switch is linked up to a 100MBit (there's playing the music...) and in another collision domain. The problem occurs in the moment we begin to stream. Maybe the problem is a lower level problem (below IP)
If I can do some tests for you let me know, today I bought a second mvp.....
klaus
hi chris,
meanwhile I feel with you......
That's really a uggly uggly uggly problem. Now that I lost some hours I shortly want to tell what happened. I took the second box today to the office for testing it after work. I'am using to machines here and both are running a vdr. Suddenly I was not able to switch a channel to annother one outside the bouquet, always channel not avail.
I observed similar situations earlier with the streamdev-plug. So I installed a newer ver of dvb-driver (from 1-0-1 to 1.1.1). But it was not perfect, I switched to a radio channel on vdr (266), and was not able to switch the mvp, I switched to a radio channel (220) resetting the mvp and was able to switch the mvp. I figured out that it was exact the channel 265, below it worked, above not. I retried that many times cause I want to find reproducable results. Then I copied this channels.conf to the other machine (1.0.1 dvb-driver) what do you think: It worked for channels above 265.....
I came back to the first machine - believe me, I didnt do any change to that system, and it was also working on that machine. During time when it not worked properly I had some getBlock timeouts in my log:
19:48:07.960817 [debug] Client - Got channel
19:48:07.960848 [debug] Client - Got schedule!s! object
19:48:07.961009 [debug] Client - Got schedule object
19:48:07.961067 [debug] Client - Got all event data
19:48:07.961129 [debug] Client - written 4 schedules packet
19:48:07.961195 [debug] Client - Waiting
19:48:07.973492 [debug] Client - Received packet, length = 16
19:48:07.973589 [debug] Client - getblock pos = 0 length = 250000
19:48:07.973635 [debug] Client - getting from live
19:48:12.560024 [debug] MVPReceiver - getBlock timeout
19:48:12.560120 [debug] Client - VDR has disconnected the live receiver
19:48:12.560151 [debug] MVPReceiver - VDR inactive
19:48:12.560893 [debug] Client - written ok 0
19:48:12.560962 [debug] Client - Waiting
19:48:12.922989 [debug] Client - Received packet, length = 4
Always when I tried to switch via mvp and I received a channel not avail. I was not able to leave the bouquet on vdr, I always had to restart the vdr to release it.
Later I tried to produce traffic on the network (filecopy and more) but nothing helped, it was running running running, I can't reproduce the earlier state. That's the sort of bug we love soo much ........
The timeout error in tcp.cc (10 sec.) wasn't seen during all the time, I think you're right, 10 secs is enough - what with my other getBlock timeouts?
klaus
At home I have two vdr-pc. Normally both are connected on a 100 MB Switch. The vomp plugin works fine.
I have an uplink from the 100 MBit switch to an 10 MB hub. The 10 MB Hub serves some older computers which are connected via rg-58 cable (my loved neighbours) to my network.
I connected the mvp to the 10 MB hub and the MVP with vomp immediatly fails to operate properly.
It loads the channel list and I'am able to selet a Channel, but then I can see the EPG and immediatly there is the "Channel not available" MSG, also I can't play recordings, same effect.
To verify the network, I connected the vdr (192.168.3.214) to the 10 MB Hub, the other (192.168.3.201) stays connected on the 100 MB switch. I'am able to use the stremdev-client on the "slow-connected" machine, also I'am able to view a recording from the (fast-connected) machine. I can copy a recording from one machine to the other, if I try to view a channel (during copy) on the other machine this works, but there are some artefacts and other disturbs - in my opinion the network is operating well, only slower.
Then I switched to ethereal and grabbed the traffic between (192.168.3.214) and the MVP (192.168.3.204).
You can download this capture here (and load it into ethereal) (I was not able to upload it here, please dl from http://videotext.dyndns.org/vomp/mvp_hang.gz .
Today a friend of mine (who is more advanced in protocol analysing) had a look at the protocol and for him it seems to be ok.
But the point I want to figure out is the following: Client on MVP is connecting, gets channels, gets EPG, then there is nothing for about 2 seconds (this is at Packet Nr.80 in the log) and then the vdr begins to send packets (and these packets are in my opinion normal data-packets of size 1542), the MVP sends ACKS, all seems to work properly, only the client on the MVP seems not to work with this data ....
so far perhaps this can help, if you need more please let me know.
klaus
Hi all,
today I tried to set up vomp on my medimvp.
Compiling and starting the vompserver (0.0.1) into vdr was no problem,
I see the message that it is started and I see the entry in the plugin
setup dialog (even if there is no option to set).
--plugin="vompserver" ...
Jan 16 23:22:54 vdr vdr[5974]: loading plugin: /usr/local/lib/vdr/libvdr-vompserver.so.1.3.37
Jan 16 23:22:58 vdr vdr[5974]: initializing plugin: vompserver (0.0.1): VDR on MVP plugin by Chris Tallon
Jan 16 23:22:59 vdr vdr[5974]: starting plugin: vompserver
vdr:/var/log #
Then I load the vomp dongle (0.1.1) into mediamvp, I see the printout from the mvploader.
#
vdr:/usr/local/etc/vdr/plugins # [bootp] packet from 192.168.13.9 : 16868 [300 bytes]
[tftp] request from 192.168.13.9 : 3909
Firmware load complete for 192.168.13.9
during that time I can ping the mediamvp
PING 192.168.13.9 (192.168.13.9) 56(84) bytes of data.
64 bytes from 192.168.13.9: icmp_seq=1 ttl=64 time=0.520 ms
64 bytes from 192.168.13.9: icmp_seq=2 ttl=64 time=0.361 ms
64 bytes from 192.168.13.9: icmp_seq=3 ttl=64 time=0.433 ms
But after the dongle upload is finished the ping gets no reply.
Then "Locating server" appears on the screen, but nothing happens.
ping is still not answered.
The mediamvp gets its ip address from a WLAN router running dhcp.
During the time when the mediamvp is booting I can see the MAC address
in the routers ARP table. After that the entry is gone even though it is still
listed in the DHCP table.
vdr 1.3.37 is running on Suse 8.2 without any firewall.
Any hint to get rid of this problem is welcome.
Kind Regards
KalleAnka
Hi KalleAnka, I'm quite surprised at where it's failed. It is past the more difficult parts of booting!
When the dongle upload is complete the MVP shuts down the network interface and passes control to the newly downloaded linux kernel. That then DHCPs its address again and it should get the same one from wherever it got it before. At that point it should start responding to pings again. I can't think why this wouldn't happen. Anyone any ideas?
When "locating server" is shown, the MVP is broadcasting UDP packets on port 3024 looking for the vompserver plugin on the network. It sounds like you know your networking, do you want to try iptraf / tcpdump / ethereal to see if that is happening?
Anyone any other ideas?
Hi Chris,
thank you for your support.
I looked a bit into the network traffic (packetyzer).
What I can see that the box get's a response to the first DHCP request, and I can see the
a lot of traffic during the firmware upload. During that time also ping
is possible.
Then the box is unreachable. The last messages it sends out are 6 DHCP requests, when linux in the
box has booted - right ?
So I guess my WLAN router (Siemens SE515) might be the course of the problem, since the box does
not get a correct answer on the second request.
I also uploaded a mediamvp dongle. After this firmware has booted I see UDP packets looking for a server.
Strange, since I read in various forums only success stories.
What do you think ?
BR
KalleAnka
Sorry, I have no idea. After the firmware has loaded to the mvp, the first DHCP requests after that will be the linux kernel trying to get an address. If those are not replied to then it will do what you are seeing. But why would your router give it an address the first time but not the second? It doesn't make any sense. And why would a Hauppauge dongle work and mine not... As far as I know they both do standard DHCP requests during kernel boot.
???
Hi Chris.
If the configured behaviour is the same the different behaviour at runtime may appear because of timing considerations. Perhaps the following test results may help:
The mvp in our studio works fine. Another mvp in our cellar forever did "Loading application" followed by "Failure to .. GUI ..". And this didn't change after both mvps were exchanged. Studio worked. Cellar didn't.
Both mvps were connected to different switches. A third switch exchanged the one in the cellar. Same problem. Then the mvp in the cellar was directly connected to the main switch of the household. And it worked fine.
(All switches are 10/100 Mbps or above. All mvps are H4. vdr is an up-to-date tobi (including vomp).)
Other devices - PCs - don't have problems while connected to the respective switches. No problems playing vdr video recordings with vlc.
Speculation:
Is it possible that vomp-client is timed out by other equipment? Perhaps because this equipment uses full duplex while vomp-client uses half duplex?
Greetings
ekluba.
@ekluba
Speculation:
Is it possible that vomp-client is timed out by other equipment? Perhaps because this equipment uses full duplex while vomp-client uses half duplex?
You could test this dongle from here http://forum.loggytronic.com/index.php?topic=358.0 (http://forum.loggytronic.com/index.php?topic=358.0)
which have included the Full Duplex Patch.
Walter
ekluba, I'm not sure why you're getting such results. As I understand it, any auto-sensing 10/100Mb switch should have the capability to deal with some devices being on half-duplex while others are on full-duplex.
Also, whether trying a full-duplex patched dongle would help depends on where in the boot up sequence it is failing. As fas as I can remember (it's a long time since I saw the Hx boot up sequence) "Loading Application" is displayed when the MVP is on the built in firmware and it is tftping a new dongle. So the new dongle code would not have started running by then, and the Hx would be in whatever duplex mode Hauppauge decided to run it in. As I remember, if it displays "Failure to locate GUI server" then it hasn't even started tftping a dongle.
As for the duplex question, I think that half duplex was selected by someone at the MVPMC project because the network chip in the MVP was not really capable of full duplex, and they had good reasons for it. I am guessing that this doesn't apply to Hx MVPs since so many people seem to prefer full duplex.
QuoteAs for the duplex question, I think that half duplex was selected by someone at the MVPMC project because the network chip in the MVP was not really capable of full duplex, and they had good reasons for it. I am guessing that this doesn't apply to Hx MVPs since so many people seem to prefer full duplex.
@Chris
I think, the full duplex patch is nowadays included in mvpmc.
Actually the reason for half duplex was that the driver in the kernel hauupauge supplied was only capable of halfduplex and they needed to backport a new driver.
Marten
Hi hondansx.
Thank you for the hint on the full duplex patch of the vompclient. Maybe I will give it a try in the future.
For now I am more interested to stabilize the loading process. And - as Chris pointed out - it is the Haupauge firmware which is responsible for the half duplex settings. So I will first try to update the Hauppauge firmware and then or additionally try to find out which network settings or hardware characteristics are responsible for the loading problems.
@all
I will report on the results.
Kind regards
ekluba.