Testers Needed!

[knutty]

ok, will do that with the logs later today, have to work now.
the buffer indicater was full and the image was shown first. then it got stuck, refreshed a few frames and then, maybe half a second later it froze completely. my english is bad, sorry, dont know how to describe it better. it was like a scratschy DVD, when the drive cant read more date. will most more infos later.

[knutty]

Have done that with the client log. could not reproduce the error i had but i managed to freeze it again. after some zapping it came up with connection lost and then froze completely.

Using a "NETGEAR DG834" router witch also does the DHCP.

[MartenR]

@knutty
I read the log you posted.
The origin of the error is clear, your TCP connection broke down. (read returned zero)
So the problem might have to reason:
1) A crash on the server side, so that the connection broke down, because there is no server anymore.
2) Network problems: a bad router etc., You might want to play with the recieive window parameter.

So the only thing we have to fix in vomp is to handle the connection lost better.

Marten

[MartenR]

A windows build for testing is attached.
Please report any bugs!
Code status: cvs + latest test code + winmain and tcp fixes.

Marten

Attachment removed due to upcoming release!

[rumi]

@MartenR

It seems to be working fine in my WLAN-Network ... also if the WLAN-connection isn't so good. Then I have dropouts in tone and picture, but the vdr-connection or the vomp-windows-client doesn't crash.

Very good job ... thank you very much.

Rumi

[Lutz]

@Marten: So far, so good! No problems!

@Chris: My MVP is now running for more than 5 days without problems!
The only issue I see is the "out of center" OSD (channel number is touching the left border), eg. after channel switching or after hitting "OK", but on the windows client it is perfectly centered.

Cheers
Lutz

[Chris]

So, I'm catching up... I finally had a good look at the tcp::read bug/fix(?) - Marten, are you now thinking that this cannot be the fix at all? Because the intention in the code is that the thread that sits in TCP::readData() at select() is protected from signals - in threadp.cc - threadPInternalStart() there is code to block signals from interrupting the newly created thread. All threads in vompclient except one should be protected this way - only the main (first created) thread should be processing signals.

aavdr: When you fixed this for the client at vdr portal, what did the fix accomplish? Does the information above fit at all?

[MartenR]

@Chris
Regarding the read data stuff, well, I have not analized the signaling stuff in detail. It just did not caused the crashes this time.
I think it is more important, that readdata is not increased in case of returning with -1.

Marten

[Lutz]

@Marten: My Vomp for windows doesn't work, I see "Locating Server", then "Connecting to Server" and then gets stuck.
The debug-Version you've provided before was working without any problems. Any idea?
Lutz

[MartenR]

@Lutz
They should be almost identical.
Please double check, if you have really the 0.3.0 windows client and the 0.3.0 server, because the symptoms are typical for a version mismatch.
The only thing which was changed compared to the test version are some debug lines and the readdata patch was removed.

Anyone else having this problem?

Marten

[carsten]

Moin,

no, released 0.3.0 server plugin/dongle with MVP/0.3.0-1 windows client all work perfect for me.

Even the D3A problem disapeard.  By buying an E1 and reselleing the D3A to a person that doesn't
use VOMP and is also happy now.

BR,
Carsten.

[Lutz]

@Marten: Uuuups, my fault... I was updating the wrong file - everything is working fine again! Thanks!!

[ekluba]

Also the dongle might not boot on wireless MVPs as I haven't fiddled the version numbers yet.

That's true. My H4s didn't boot until the version numbers were increased. See:
http://www.loggytronic.com/forum/index.php?topic=355.0

Greetings
ekluba.