Messages

Finally I had time to test this.

Copied CVS version which seemed to have those changes allready from hondan diffs  so no patching needed. Compiled the server and copied it to /usr/lib/vdr (which is used in fedora) and restarted vdr.

Then I restarted client also just to be on the safe side but there were no change

Timeout is propably not the reason because it takes only a couple of secons to get the listing on the screen.

LSTR shows recordings that are not seen on the client.

\\Kartsa

What do I need to get this tested? Environment? Compiler? Where's the source? Edit: I assume I need to set up development environment

Btw, same problem can be seen with windows client. Could this mean that the problem lies in server side?

Actually I had 2 usb drives connected to vdr server which made the total recording size roughly about 700GB. So there is a lot of recordings I noticed just now that there were missing recordings from here and there when the recordings were sorted alfabetically. So I assume that the cause may be one or both of those you mentioned. If I understand correctly 2 should only apply to cases where the length is too long. I might have those but the funny thing is that I had such recordings on the list that are deeper in the tree structure while missing some that are higher. So propably my problem is timeout which most likely is due to the amount of my recordings. I did not try reconnecting but I did unmount those usb drives and now I can see recordings that were missing.

Just out of curiosity. You wrote that the client would disconnect in case of timeout. Would that mean a real disconnect where the client starts over and goes to main menu? If so that did not happen. Also the list of recordings comes in about less than two seconds and as said there are recordings missing from the top level also. That is recordings that are on the vdr servers harddisk not on the usb drives. And to clarify more those missing recordings can be seen when the usb disks are unmounted.

And I would also like to thank Chris for an outstanding piece of software.

I happened to notice that when I have an external harddisk (usb) connected to vdr server and mapped to a directory under vdr recordings directory womp does not show all recordings on that drive/directory. I tried to search for if this is a known feature (bug) but could not find anything.

As said I have an external usb drive which has 90 some recordings on it. There is also one tv-series there which has 60 some recordings. Womp shows only these recordings and no others on the same disk. The others are shown normally on vdr but not on womp.

No there is not. And now I left a channel on for a couple of hours and there were no crash. Next I'll try a recording on full screen. I know I have had problems with watching recordings but I will test this once more to be absolutely sure.

I tested with a recording on full screen and I noticed that it freezed after about 5 mins of watching. The picture actually freezes as if it were paused. After switching to window mode womp screen turns all white.

As I mentioned in my first post I have not been able to see any pattern on the behaviour. It may even have something to do with the video drivers because when this appears windows kind of stops responding (or at least there is no screen update) for a few seconds and the whole screen goes black for a second or so. After that all returns normal except the womp client has stopped responding and the womp window is all white. But I do not know which occurs first or which causes what. What I do know is that if I view in window mode and switch to another window it most likely halts in some seconds. But it does halt in full screen also without switching to another program. I'll try to watch some TV program if I can reproduce the problem.

I am not quite sure which decoder I had earlier but I did have PowerDVD5 installed. I then installed K-Lite Codec Pack because I suspected the codecs. There were no change. I then thought I would use graphedit to check the codecs but there were no DVD Navigator (I used graphedit directx 9.0 build 021204 and tried to follow the instructions on http://www.linuxtv.org/vdrwiki/index.php/How_to_determine%2Cwhich_MPEG2-Decoder_Vomp_for_Windows_uses_or_if_I_have_an_compatible_MPEG2_decoder_filter_installed). How can I check what decoder womp uses?

On network side I do have firewall on both machines but on both I've allowed all traffic on local net (192.168.1.0/24). I have not tried without firewalls. I have a 10/100 D-Link switch.

I have not found any reason or any pattern when or in which situations this happens but the client can hang several times during a playback of a recording. This may happen in full screen and window mode. If client has stopped responding changing between full screen and window mode leaves screen blank (white). It can only be stopped (i.e. alt+F4). Sometimes after restarting the client playback can be resumed where it hang but sometimes the playback starts from the beginning.

This is what is last in the log
20:19:47.000437 [debug]  Command - processing message 25
20:19:47.000437 [debug]  Command - Sending message to viewman
20:19:47.000437 [debug]  VVideoRec - Message received
20:19:47.000437 [debug]  Command - processing message 25
20:19:47.000437 [debug]  Command - Sending message to viewman
20:19:47.000437 [debug]  VVideoRec - Message received
20:19:47.000453 [debug]  Command - processing message 25
20:19:47.000453 [debug]  Command - Sending message to viewman
20:19:47.000453 [debug]  VVideoRec - Message received
20:19:47.000468 [debug]  Command - processing message 25
20:19:47.000468 [debug]  Command - Sending message to viewman
20:19:47.000468 [debug]  VVideoRec - Message received
20:19:47.000484 [debug]  Command - processing message 25
20:19:47.000484 [debug]  Command - Sending message to viewman
20:19:47.000484 [debug]  VVideoRec - Message received
20:19:47.000500 [debug]  Command - processing message 25
20:19:47.000500 [debug]  Command - Sending message to viewman
20:19:47.000500 [debug]  VVideoRec - Message received
20:19:47.000515 [debug]  Command - processing message 25
20:19:47.000515 [debug]  Command - Sending message to viewman
20:19:47.000515 [debug]  VVideoRec - Message received
20:19:48.000875 [notice] Core - Window closed, shutting down...
20:19:48.000875 [notice] Core - Window closed, shutting down...
20:19:48.000875 [debug]  VVideoRec - Pre stopPlay
20:19:48.000875 [debug]  Player - Stop called lock
20:19:48.000875 [debug]  Player - Switch state from 1 to 6

Any idea?

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 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?

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.

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.

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.