Problem - opening Recordings

[GTRDRIVER]

Hello

Here i have a VDR - a lot of HD-Space and 4 VOMP-MVP´s in the Netwrok.

Viewing LiveTV works well (VOMP on Cable LAN and VOMP on WLAN) but if i open Recording after a view Seconds VOMP hangup and display "Lost Connection".
After pressing ok and reconnect to the server i can again choose Recording - and i get the same error.
If i do this 4-5 times i get my Recordings-List.

I have played arround with:

sendBuffer = new UCHAR in mvpclient.c - but this don´t help.

Perhaps it´s a timeout-Problem - but i don´t know.


At the /video Dir at the moment there are 1600 recordings wich means 4,1TB used Space

Can anyone help me to debug this problem and fix it ? - i Love Vomp but this is realy bad....

CU
Axel


Here the vomp.log:

19:46:40.658169 [debug]  Client - Received packet, length = 4
19:46:40.658279 [debug]  Client - SwitchOp
19:47:50.162924 [debug]  Client - recorded size as 210256
19:48:00.161069 [debug]  TCP - TCP has closed socket
19:48:00.161175 [debug]  TCP - TCP: error or timeout
19:48:00.161238 [debug]  Client - Written list
19:48:00.166364 [debug]  Client - Waiting
19:48:00.166468 [debug]  Client - Received packet, length = 4
19:48:00.166484 [debug]  Client - Detected connection closed
19:48:00.166499 [debug]  Client - MVP client destructor
19:48:00.166513 [debug]  Client - Clean config

[MartenR]

I would guess, that it is a timeout problem. You should increase the timeout threshold, I think it is in the TCP base class of the client somewhere, but I don't know it exactly.

Marten

[GTRDRIVER]

Hmm

Hi - Thanks for your hit

Can anyone help me to find what i have to change.

CU

[GTRDRIVER]

a new hit:

I have tryed the WINDOWS-Client with the same Server - and: the same Problem !

Another interesting Thing: it seems that when the Plugin collected the Data (Recordings) for 2-4 Minutes everything works fine - after that the game begis from the beginning..

CU

[Chris]

Hi, I think changing the TCP timeout in the client will solve your problem, as Marten said. In my copy of the tcp.cc file line 154 has a value for the timeout in seconds. It is set to 10 seconds at the moment because it is the same timeout used for all communications to VDR, and in most cases, if VDR doesn't respond to something within 10 seconds then something has gone wrong. A very large recordings directory could take longer than 10s to scan through which would make the client think that the server has dropped the connection. The reason why it could work a second time almost straight away is that the server computer would have all the file system data cached and it would be able to scan through the data in memory rather than going to disk.

I have added the problem to my to-do list, but it's not solvable simply. If I just changed the timeout to a minute then all errors would only be detected after a minute and MVPs would seem to lock up for that time.

[GTRDRIVER]

Hi

Thanks for your post

I think this is possible and it sound plausible.

For testing - is it possible for me to change this value in the Client Source and compile it ?

Do i have to compile a new dongle or do you mean the Win-Client ?

CU
Axel

[Chris]

Either, the problem is the same for the dongle and Windows versions.

If you havn't got a development environment set up for the dongle, try the latest makedevenv script - it seems to be quite reliable.

[GTRDRIVER]

Hello again.

I thinks there runs something wrong:

++ GCC_DIR=gcc-3.4.5
++ GLIBC_DIR=glibc-2.2.5
++ LINUX_DIR=linux-2.6.8
++ GLIBCTHREADS_FILENAME=glibc-linuxthreads-2.2.5
++ EXTRA_TARGET_CFLAGS=-fno-unit-at-a-time
++ sh all.sh --notest
DEJAGNU not set, so not running any regression tests
GLIBC_ADDON_OPTIONS not set, so building all glibc add-on's
KERNELCONFIG not set, so not configuring linux kernel
+ TOOLCOMBO=gcc-3.4.5-glibc-2.2.5
++ pwd
+ BUILD_DIR=/tmp/vompclient/crosstool/crosstool-0.43/build/powerpc-405-linux-gnu/gcc-3.4.5-glibc-2.2.5
++ pwd
+ TOP_DIR=/tmp/vompclient/crosstool/crosstool-0.43
+ test -z ''
+ SRC_DIR=/tmp/vompclient/crosstool/crosstool-0.43/build/powerpc-405-linux-gnu/gcc-3.4.5-glibc-2.2.5
+ echo 'SRC_DIR not set, so source tarballs will be unpacked in the build directory'
SRC_DIR not set, so source tarballs will be unpacked in the build directory
+ abort 'Don'\''t run all.sh or crosstool.sh as root, it'\''s dangerous'
+ echo 'Don'\''t' run all.sh or crosstool.sh as root, 'it'\''s' dangerous
Don't run all.sh or crosstool.sh as root, it's dangerous
+ exec false
tvserver:/tmp/vompclient/crosstool#

can you tell me what´s wrong here ?

[Fourty2]

I thinks there runs something wrong:
[..]
Don't run all.sh or crosstool.sh as root, it's dangerous

can you tell me what´s wrong here ?

You are working als root... :-)

This needs some editing of scripts and running cross-compiler build "by hand".
Afterwards you must comment-out the cross-compiler-build in makedevenv-script an run it again.

Maybe it is much better to do a simple adduser...

Fourty2

[riban]

We have been experiencing a similar problem recently. We currently have 132 recordings in the list. It often happens that we watch a recording then after stopping it, we get a lost connection message. It also happens when after deleting a recording but less often when just accessing the recordings list from the main menu. It certainly seems to have gotten worse recently. This could be because I have a temporary setup in our new house which may be reducing network speed (hence aggravating any timeout problems).

[GTRDRIVER]

Hi

That´s also the PRoblems i have - but also at opening the Recordings- List

Now i have tryed to change the Timeout in the tcp.cc  to 20 and to 40 sec and build a new dongle.

Still the same problems...

[muellerph]

It often happens that we watch a recording then after stopping it, we get a lost connection message. It also happens when after deleting a recording but less often when just accessing the recordings list from the main menu. It certainly seems to have gotten worse recently.

This behaviour I have too (same points of crashes), but our recording lists are normally in the range of max 20 - 30 entries.
So I would say, this "lost of connenction" is not bound to the number of entries in the recording list.

I don't have networking issues (at least I'm not aware of any)

[MartenR]

It may take longer to get the recordings list if other files than the vdr recordings are in the recordings directory. Than vdr will scan also these files and this can cause that the delay is activated.

But I think the general beviour of the network command should be change maybe that not all recordings are transfered at once but 10 at once ao that we would not run into the delay.

Marten

[Chris]

Well this is interesting. I don't have any regular crashes at all.. (or I would certainly have fixed it!)

I knew about the problem with extremely large collections of recordings, but 100-200 I wouldn't call extremely large. gtrdriver trying a 40s timeout convincingly proves that something else is going on. So.... any more clues anyone?