I have one machine which acts as a test environment on which I have compiled vompserver. Then I have another machine which acts as my normal vdr device. I have copied the compiled vompserver to the normal vdr device and both macines are running. When I start windows client I get a list of servers as I should but when I select my test machine the client just dies. It works fine on the normal vdr machine. They are both in the same private network with identical vdr versions and linux versions. Even iptables are the same. And on both machines I get the same line in the log:
ERROR: plugin '<no name given>' called cPlugin::ConfigDirectory(), which is not thread safe!
How do I find out why its working on one but not in the other? The funny thing is that it worked on the test machine while I was testing it in the beginning.
Anybody? I really am out of ideas. :'(
I have no idea what it can be, but I'll ask some standard questions to get closer to the problem.
1) Version of the vompserver plugin on your two vdr machines? Are they identical and equal to 0.2.5?
2) Plattform of your two servers, Distribution, Intel Prozessor?, 32 Bit or 64 Bit?, Endian ?, gcc version?, libc ?
1) Yes, they are both 0.2.5.
2) Fedora Core 6, with 2.6.18 kernel, 32 bit version (both). Test environment is with Intel PIII 550MHz and the other is with AMD 3000+. Gcc 4.1.1, libc-2.5.
The funny thing is, that it did work with the test environment when I tested it before copying the libvdr-vompserver to my normal vdr machine. And I can not recall I changed anything.
I have ordered a Hauppauge MediaMVP but havent got it yet so I can not say how it will behave but I should know that in a couple of weeks.
Moin,
the above mentioned line in syslog doesn't seem to be connected to the issue, as it appears in my logs every now and then also, while everything is running.
BR,
Carsten.
Hmm, I don't have any ideas except for one silly thing. Disconnect one of the servers from the LAN and try again.
Maybe there is an error in the server selection code.
Marten
Actually I tried that already and it had no affect. There is ofcourse no selection of server and the client just exits after searching server.
And the line in the log is identical between the working and nonworking environments.
Maybe you can use ethereal or wireshark to sniff the network communication to detect the difference between the two servers.
Marten
I tried wireshark (on windows client) but my knowledge on tcp/ip is propably not good enough cause I do not know what to look for ???
I sniffed both environments with a series of tasks where I started vompclient and selected the server from the list. Nonworking environment ofcource exited at this point. On working environment I then just excited the client manually.
Then I used wiresharks "expert info" and the difference between the two results was a Keep-Alive <-> Keep-Alive ACK pair on the working environment. I filtered all traffic between client and server.
Any hint how the comparison can be done?
This is the non working log
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.11 192.168.1.100 UDP Source port: 3024 Destination port: 3024
2 5.747812 192.168.1.100 192.168.1.11 TCP 1467 > 3024 [SYN] Seq=0 Len=0 MSS=1460
3 5.748080 192.168.1.11 192.168.1.100 TCP 3024 > 1467 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
4 5.748112 192.168.1.100 192.168.1.11 TCP 1467 > 3024 [ACK] Seq=1 Ack=1 Win=65535 Len=0
5 5.762219 192.168.1.100 192.168.1.11 TCP 1467 > 3024 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=14
6 5.762408 192.168.1.11 192.168.1.100 TCP 3024 > 1467 [ACK] Seq=1 Ack=15 Win=5840 Len=0
7 5.763656 192.168.1.11 192.168.1.100 TCP 3024 > 1467 [PSH, ACK] Seq=1 Ack=15 Win=5840 Len=12
8 5.768227 192.168.1.100 192.168.1.11 TCP 1467 > 3024 [PSH, ACK] Seq=15 Ack=13 Win=65523 Len=25
9 5.790321 192.168.1.11 192.168.1.100 TCP 3024 > 1467 [PSH, ACK] Seq=13 Ack=40 Win=5840 Len=10
10 5.800717 192.168.1.100 192.168.1.11 TCP 1467 > 3024 [PSH, ACK] Seq=40 Ack=23 Win=65513 Len=38
11 5.801181 192.168.1.11 192.168.1.100 TCP 3024 > 1467 [PSH, ACK] Seq=23 Ack=78 Win=5840 Len=8
12 5.801841 192.168.1.100 192.168.1.11 TCP 1467 > 3024 [PSH, ACK] Seq=78 Ack=31 Win=65505 Len=33
13 5.802126 192.168.1.11 192.168.1.100 TCP 3024 > 1467 [PSH, ACK] Seq=31 Ack=111 Win=5840 Len=15
14 5.802659 192.168.1.100 192.168.1.11 TCP 1467 > 3024 [PSH, ACK] Seq=111 Ack=46 Win=65490 Len=33
15 5.802936 192.168.1.11 192.168.1.100 TCP 3024 > 1467 [PSH, ACK] Seq=46 Ack=144 Win=5840 Len=8
16 5.804889 192.168.1.100 192.168.1.11 TCP 1467 > 3024 [PSH, ACK] Seq=144 Ack=54 Win=65482 Len=37
17 5.805752 192.168.1.11 192.168.1.100 TCP 3024 > 1467 [PSH, ACK] Seq=54 Ack=181 Win=5840 Len=8
18 5.806359 192.168.1.100 192.168.1.11 TCP 1467 > 3024 [FIN, ACK] Seq=181 Ack=62 Win=65474 Len=0
19 5.830900 192.168.1.11 192.168.1.100 TCP 3024 > 1467 [FIN, ACK] Seq=62 Ack=182 Win=5840 Len=0
20 5.830946 192.168.1.100 192.168.1.11 TCP 1467 > 3024 [ACK] Seq=182 Ack=63 Win=65474 Len=0
And this is the working log
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.10 192.168.1.100 UDP Source port: 3024 Destination port: 3024
2 4.463455 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [SYN] Seq=0 Len=0 MSS=1460
3 4.463631 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
4 4.463656 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [ACK] Seq=1 Ack=1 Win=65535 Len=0
5 4.465204 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=14
6 4.465340 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [ACK] Seq=1 Ack=15 Win=5840 Len=0
7 4.465820 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [PSH, ACK] Seq=1 Ack=15 Win=5840 Len=12
8 4.470658 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [PSH, ACK] Seq=15 Ack=13 Win=65523 Len=25
9 4.470922 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [PSH, ACK] Seq=13 Ack=40 Win=5840 Len=10
10 4.482957 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [PSH, ACK] Seq=40 Ack=23 Win=65513 Len=38
11 4.483146 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [PSH, ACK] Seq=23 Ack=78 Win=5840 Len=8
12 4.483810 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [PSH, ACK] Seq=78 Ack=31 Win=65505 Len=33
13 4.483929 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [PSH, ACK] Seq=31 Ack=111 Win=5840 Len=8
14 4.484355 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [PSH, ACK] Seq=111 Ack=39 Win=65497 Len=22
15 4.484476 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [PSH, ACK] Seq=39 Ack=133 Win=5840 Len=8
16 4.485477 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [PSH, ACK] Seq=133 Ack=47 Win=65489 Len=28
17 4.485617 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [PSH, ACK] Seq=47 Ack=161 Win=5840 Len=8
18 4.486209 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [PSH, ACK] Seq=161 Ack=55 Win=65481 Len=18
19 4.486326 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [PSH, ACK] Seq=55 Ack=179 Win=5840 Len=8
20 4.486763 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [PSH, ACK] Seq=179 Ack=63 Win=65473 Len=20
21 4.486879 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [PSH, ACK] Seq=63 Ack=199 Win=5840 Len=14
22 4.494633 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [PSH, ACK] Seq=199 Ack=77 Win=65459 Len=36
23 4.494812 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [PSH, ACK] Seq=77 Ack=235 Win=5840 Len=8
24 4.495521 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [PSH, ACK] Seq=235 Ack=85 Win=65451 Len=36
25 4.495906 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [PSH, ACK] Seq=85 Ack=271 Win=5840 Len=8
26 4.684934 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [ACK] Seq=271 Ack=93 Win=65443 Len=0
27 7.683789 192.168.1.10 192.168.1.100 TCP [TCP Keep-Alive] 3024 > 1671 [ACK] Seq=92 Ack=271 Win=5840 Len=0
28 7.683824 192.168.1.100 192.168.1.10 TCP [TCP Keep-Alive ACK] 1671 > 3024 [ACK] Seq=271 Ack=93 Win=65443 Len=0
29 8.212301 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [PSH, ACK] Seq=271 Ack=93 Win=65443 Len=37
30 8.212808 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [PSH, ACK] Seq=93 Ack=308 Win=5840 Len=8
31 8.213426 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [FIN, ACK] Seq=308 Ack=101 Win=65435 Len=0
32 8.213532 192.168.1.10 192.168.1.100 TCP 3024 > 1671 [FIN, ACK] Seq=101 Ack=309 Win=5840 Len=0
33 8.213551 192.168.1.100 192.168.1.10 TCP 1671 > 3024 [ACK] Seq=309 Ack=102 Win=65435 Len=0
The only thing this tells me is thät the communication is just stopped in the non working environment after 20th frame. Or that on the 17th frame is happening something that causes the communication to end.
This is the 17th datablock of the non working
0000 00 20 ed bd 14 df 00 01 02 a2 af d6 08 00 45 00 . ...... ......E.
0010 00 30 47 01 40 00 40 06 70 07 c0 a8 01 0b c0 a8 .0G.@.@. p.......
0020 01 64 0b d0 05 bb 14 10 38 71 82 d6 8e 22 50 18 .d...... 8q..."P.
0030 16 d0 a6 2a 00 00 00 00 00 04 00 00 00 01 ...*.... ......
And this is the 17th datablock of the working
0000 00 20 ed bd 14 df 00 17 31 65 29 3c 08 00 45 00 . ...... 1e)<..E.
0010 00 30 74 fe 40 00 40 06 42 0b c0 a8 01 0a c0 a8 .0t.@.@. B.......
0020 01 64 0b d0 06 87 65 72 b9 61 0a 3e 20 ea 50 18 .d....er .a.> .P.
0030 16 d0 b8 de 00 00 00 00 00 04 00 00 00 00 ........ ......
There are some differences but do those differences tell anything?
Ok, we see one thing, that the UDP stuff works. So the error must be caused by some TCP command.
One thing I miss for the interpretation is, that I don't know in which direction your 17th frame travells from server to client or from client to server.
Maybe I tell you something about vomps protocoll. The clients sends a message through tcp (payload) of the form
AA AA AA AA BB BB BB BB payload
Here is AA AA AA AA the length of BB BB BB BB + payload and BB BB BB BB is the message typ. (Of the BB would only one BB non zero, we have yet only 20 something commands).
Then the server responds with
AA AA AA AA payload
where AA AA AA AA is the length of the payload.
So what we need to know is what the client has asked last before the crash and the servers answer. (And this for both servers.) Then I can compare inside the code, what caused the crash.
Marten
Ok, this actually helped me. I took a look whats in the conf file on the server and there was Last Power State = Off. Changed it to On and now it works :) I do not know how this was changed :)
In the 14th frame client sent "General Last Power State" to server to which the server responded in the 15th frame with string Off.
Seems that when I exit the client it sets the last power state to off thus causing the client to exit after server selection. But the real reason is probaply Power After Boot setting. In the non working environment it is Last State but totally missing from the working environments conf file.
I will make the options menu and the options version dependent, so that options which are nonsense for the windows version will not appear. Like this option.
Marten