Loggytronic Forum

As of this post I have completed my to-do list for the next release of vomp, it is now safe to run as far as I know. Much has changed since the last release and so, I would like anyone who does or could run a bleeding edge cvs version of vomp to have a go and give it some testing.

One thing to note - you will need to copy the l10n directory from the vompserver plugin source directory into the vompserver plugin config directory. To put it another way, in the same directory as your vomp.conf and vomp-mac.conf, there now needs to be the l10n directory.

If you run "cvs upgrade" on the server you will need the "-d" switch to build new directories.

If all goes well I will properly release it in a couple of days.

Thanks!

Works great so far.
Both dongle and plugin compiled flawlessly. Had some problems though getting the dongle to be downloaded to the client until I realized the new vompserver plugins directory. Moved my existing vomp.conf file to the vompserver plugins directory and the dongle was downloaded just fine.

The new builds will be put under more stress tomorrow when the rest of the family begins watching tv on their boxes...

- Magnus

Hello Chris,

I'm going to test it, for sure.
And MANY MANY THANKS for spending so much time on this development.

But I also have some thoughts:
A) May you consider adding a versioning string to the protocol?
See: Next version: Numbering scheme and possible more often updated dongles (http://www.loggytronic.com/forum/index.php?topic=308.0)
I would propose to do it in the UDP broadcast as this protocol most probably won't change regardless of how the normal client <-> server protocol is defined.

B) The Patch: Scrolling long EPG description  (http://www.loggytronic.com/forum/index.php?topic=295.msg1804) is not included.
I know it doesn't apply cleanly to the latest CVS and I don't have an updated one at the moment. But as this is one of the big ones in the Wishlist, any chance to include it within the next release?
I'm going on vacation with the family this Friday for 2 weeks, so I don't have hope to get it updated within the next 3 weeks.
The changes needed shouldn't be too drastic, but still some work to do - i.e. maybe the new boxstack gives some more troubles to implement cleanly.

Because of B) I would like to have A) implemented. B) is at the end only a small change in the GUI, so with a small update of the dongle we could do a 0.x.y+1 release within a short timeframe.

Compiled and started fine.

Random issues:
- JPEG showing works, but if I press back box hangs, seems to be same issue as with MP3 - also mentioned in Vomp-Media-Player thread
- Previously it was possible to scroll in live TV through the epg with up and down for the next entries. Is this still possible and in case yes which keys to use?

I have discovered a threading problem in the server plugin. After a few MVP startups (for me anyway) connecting to VDR will stop working. This is now fixed in cvs, please  update and recompile.

Other issues in this thread to follow ...

Hi Chris,

wow, the new client gui looks really nice.  :)
One problem so far. My vompserver plugin config directory lies under the mainroot as mentioned here
http://www.loggytronic.com/forum/index.php?topic=335.0 (http://www.loggytronic.com/forum/index.php?topic=335.0)


/(null)/plugins/vomp/vomp.conf


vdr is starting with -P'vompserver -c vomp'.
Version 0.2.7 did not have this problem.

Another thing:
Waking up the vdrserver with wol is implemented so far. Is there any main reason, why the according shutdownpatch is not implemented from here?

http://www.pompase.net/joomla/index.php?option=com_remository&Itemid=33&func=select&id=5 (http://www.pompase.net/joomla/index.php?option=com_remository&Itemid=33&func=select&id=5)


Many THX,
Walter

I'm running your 'latest' CVS update, and twice this evening the client has stopped responding to the remote. In each case I opened the 'Timer' menu (which has two entries) then went back to the main menu using the 'Back' button. The problem is that it's not repeatable; I've also been flipping around the menus and watching live and recorded TV for a couple of hours with no problems. There is nothing in the server logs.

I've been tracking the CVS versions for months and this problem has only just occurred.

OK, backing out of a JPEG is now fixed.

@muellerph:

I am guessing you are using an old style remote? I seem to have lost mine, so I am slightly in the dark. Are you finding that up and down are scrolling the now/next data rather than changing channel?

Version info in the protocol: Yes, but I'm not sure about doing it for this version. Fear not though, while this release has taken so long because of the enormous change to the protocol, there is no such blocker for future releases, so they can progress much faster. The same goes for scrolling of EPG descriptions.

@hondansx:

From your other post it looks more like vomp is opening the config file but just not finding that information in it. I'm not sure what your issue is with the config location, what happens when you don't supply the -c parameter? As far as I remember the default location now is [plugins]/vompserver/ for config files.

@davep:

Confirmed. It will be due to my latest BoxStack update. I will look at that next.

Quote from: Chris on June 02, 2008, 21:13:19
@muellerph:
I am guessing you are using an old style remote? I seem to have lost mine, so I am slightly in the dark. Are you finding that up and down are scrolling the now/next data rather than changing channel?

Yes I have 4 MVPs and 5 old remotes.
The other way round. I can change the channel, but not scroll the now/next data. Would be good to have some keys to use here as I found it useful.
The old behavior was: When now/next data was shown, the up and down was scrolling through them, when there was no now/next it was switching the channels.

Quote
Version info in the protocol: Yes, but I'm not sure about doing it for this version. Fear not though, while this release has taken so long because of the enormous change to the protocol, there is no such blocker for future releases, so they can progress much faster. The same goes for scrolling of EPG descriptions.

I was thinking of it and the more I think about it, it should just be an attachment to the name the server sends back when doing the UDP broadcast. Just add 6 digits in brakets which could send the versioning info. I don't think this string needs to be overengineered. So something like "vdr (000208)" for the 0.2.8 could be the answerstring from the server. Future clients would be able to read and compute it, old would just display the version in brakets additionally. Just the server would need to be updated for the moment, the client can use the info in a later step.

Quote
@davep:
Confirmed. It will be due to my latest BoxStack update. I will look at that next.

I can confirm as well. I had 0 timer entries.

Okay leaving out the -c parameter did help to find the vompserver directory.
The -c parameter seems to be ignored.

Walter

muellerph:

The java remote simulator is sending the wrong codes for the old remote, that's why I had it the wrong way around. Can you try the code now, I think it might do what you  want.

Quote from: Chris on June 02, 2008, 21:47:09
muellerph:
The java remote simulator is sending the wrong codes for the old remote, that's why I had it the wrong way around. Can you try the code now, I think it might do what you  want.

Yes, works now again as expected. Thanks.

When I get a "channel unavailable", the OSD keeps showing with a black background. So far ok.

But if I then press back, the OSD is removed and I get a black screen.

If I then press "back" again, I come back to the channellist.

This black screen in between is a bit confusing as it rather looks like the box has crashed (which is not the case here).

This happens with TV as well as radio.

The possible hang backing out of the timer list is now fixed, along with the same bug in a handful of other places.

OK, if the channel is unavailable the back button now backs completely out of tv.

Hi,

so far so good, I managed to compile the cvs plugin and dongle. Wanted to load dongle only on my experimental
MVP (handled through the config entry to point to either dongle file). But: 0.2.8 dongle will not run with "0.2.9.rc1"
plugin, as it doesn't work with software client. Is this intentionally and do we have an idea how to easily run rc1 and
0.2.8 together with one server?

BR,
Carsten.

Maybe I got your question wrong.
I think you mean you have a normal 0.2.7 server and want to try the current dongle / client 0.2.8rc1 out of cvs.
Also the other way round 0.2.8rc1 serverplugin and 0.2.7 client.
Both for sure won't work, as the network protocol has changed fundamentally.

But I also have only 1 productive server. I managed the trick with another server in a virtual machine which gets all data from the normal server via streamdev-plugin. The server in the virtual machine has now the vomp-plugin from 0.2.8rc1.

I described already my setup in this forum (http://www.loggytronic.com/forum/index.php?topic=265.0).

Works like a charm. No problem with the family and also full flexibility for development.
Only negative sideeffects are:
- Switching channels is a bit slower (as it needs the roundtrip through streamdev-plugin)
- Live-TV and recording a program is not possible, as streamdev is 1 channel only at the same time
Both are not a problem for a dev environment.

Moin,

Volltreffer! I will use your recomendations to further try out developments, whilst neither disturbing myself
and my wife in the livingroom nor my elder son with Marten's software client.

VDR is anyhow running under XEN in a media DomU, together with SAMBA and a DAAP mediaserver.

Thanks a lot.

hey all,

can anyone build a dongel an load it up to download for such people who can't build one ?!

thanks :-)

Send me your email to c a r s t e n < a t > s c h i e r s < d o t > d e and I could try to set up
the latest dongle and the plugin against debian vdr 1.6.0 from e-Tobi. BR Carsten.

May I also...?
Lutz

You've got mail. I have no idea, whether it will work for you, but why not...BR, C.

Hi Chris,
I've just managed to install the precompiled dongle and plugin I've got from Carsten, works so far, but when I do some channel switchicng, the box freezes and needs a power cycle reboot.
The same was before, with V. 0.2.7, but not so often.
The box I'm actually testing with is Model E1.
Later I will try to compile the plugin itself on my machine, but Carsten is using the same version of VDR from Toby's repository, so this shouldn't be the reason...
Regards
Lutz

Hi Chris,
I've now managed to compile the plugin for my system, but I can' get the makedevenv-script working; could you consider to offer an actual cvs-dongle for download, just to be shure to test with a right one?
Regards
Lutz

Hello Chris,
I just finished my own dongle, but no difference, I can switch a while, and suddenly while switching it freezes, exactly whilst hitting  the button. Sonmetimes OSD continues
to work  a moment, most times I just get the led flashing with the rc buttons...
I allways was thinking my network is OK...  I can easyly watch 6 streams or even more with the mvp, vomp on windows and vlc clients... no probs...
Cheers
Lutz

@Lutz
I get the same while heavyly testing the windows client code. At the moment I have no clue why this happens, I just see in the debugger that there is data transmitted and there is no streamreceiver present...

Marten

Some update I have trace it back. The origin is that, if you are doing heavily channel switching, there can be to request to the vdr at once, which is currently not supported in the plugin code.
So the client is waiting infinitely for a response of the server...
At the moment I am unsure, if this is a bug on the client side or if it should be added to the server side.
But may be I will supply a fix for this soon...
@Lutz
Do you have on the server side in the vomp log file:
[ERR]  RRProc  - recvReq err 1
?

Marten

@Lutz
Here is a quick fix, please replace the attached files at the serverside and compile and build and tell me, if it is gone.

Marten

@Marten

I don' find "[ERR]  RRProc  - recvReq err 1" in the vomp.log.

I've tried the files, but it doesn' t make a difference for me!

Lutz

@Lutz
Hmm, then it is a different error and my issue may be windows specific...
Since it does not crash on my machine anymore, the error is hard to guess...

Marten

@Marten,
at all I don't see any errors in the log...

@Chris: when the MVP freezes, the connection seem to stay, in the log I find "Num of mvp receivers up to 2" with just one box connected.


@all: anyone else with this kind of problem?

Lutz

could be the same problem I fixed in the 027 variant at vdr portal - interrupt (coming from key press) is handled as an error when waiting for data.
Currently I've got no time to test by my own, but the fix was in tcp.cc on the client side:
Just after select in readData (line 293 in current cvs)
#ifndef WIN32
      if (success < 1 && (errno == EINTR) )continue;
#else
      if (success < 1 && (WSAGetLastError() == WSAEINTR) ) continue;
#endif

Maybe someone can try this out. In theory this should also be handled for read but the chance for hitting a key when reading is much smaller then during select - so maybe not really necessary.

Regards
Andreas

Firstly let me say I don't see these errors at all on my setup (otherwise I would have fixed them in the first place :) ).

Just in case anyone is wanting a cvs dongle & server they are attached, but they don't have any of the fix files in that are in this thread. That is because I have the following initial thoughts about those fixes (I haven't had time to look at the code yet, so these are flying-blind comments...)

1. Marten - your theory that multiple requests are getting from client to server - yes this would screw up the server, I agree. But also the client as yet should not be sending multiple requests. As per my current design I don't know how it is doing that.

2. Andreas - As far as I remember the program will be sitting in select most of the time - surely many button presses occur and don't cause problems when the networking in in a select. Are you sure it's not the recv? I can see that being more susceptible to problems (but as you say, far less likely to happen).

I'll be combing the code later, I just wanted to get these files posted.

@Lutz: I am surprised to see that you are getting the message "Num of mvp receivers up to 2" in the server log - there is timeout code in the server to stop this from happening. Could you watch the log and make sure it is killing off the clients after a certain time? It should waffle on about your existing recordings when it kills a client. Also when you next log in, the mvp count should logically go up to 1....

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


-- Edit: Attatchments removed, get the later versions instead

@Chris: you are right, the number is going down to 0 again.

One point: For the freezing I do not  have to do heavy channel switching, it also happens occasionally when I just switch to the next channel after a while; if I do heavy switching it happens for shure...

Lutz

@Chris
Well, it does happen(only on windows), I can see it clearly in the logs.
Actually it is a request Number 8 and 10 at the same time. So epg data and start streaming, one from the player and the other from the view. It might be that a locking mechanismen is not working on windows(which I have to fix), so is there a locking mechanismen to prevent the two request one from the player thread and one from the view?
After I fixed the server side it is working at might setup without problems, it might be that the network timing is different on your setup.

Marten

@Andreas: Your patch helps indeed, but it is not perfect. I can do a lot channel switching, but occasionally it freezes again.

Lutz

Marten or Lutz: Could you post a client log of the freeze, hopefully when these two requests go out at the same time.

Thanks

@Chris: I've attached two logs, vomp-1.log is with Avdr's patch till the freeze, vomp-2.log is with your plain dongle, also till the freeze... but I don't see nothing special...

Lutz

@Chris
Here the important part at the client lock time: (The same file is attached to this message)

Quote19:28:08.000578 [debug]  BoxStack - Unlocked for update
19:28:08.000671 [debug]  VVideoLiveTV - Set player to channel 16
19:28:08.000671 [debug]  PlayerLiveTV - setChannel
19:28:08.000671 [debug]  VVideoLiveTV - Done Set player to channel 16
19:28:08.000671 [debug]  VDR - RR 10
19:28:08.000671 [debug]  VDR - RR sleep
19:28:08.000671 [debug]  PlayerLiveTV - start new stream
19:28:08.000671 [debug]  PlayerLiveTV - Switch from state 4 to state 2
19:28:08.000671 [debug]  VDR - RR 8
19:28:08.000671 [debug]  VDR - RR sleep
19:28:08.000687 [debug]  VDR - Rxd a response packet, requestID=105, len=13306
19:28:08.000687 [debug]  VDR - RR unsleep
19:28:08.000687 [debug]  VDR - Success got to end of getChannelSchedule
19:28:08.000703 [debug]  BoxStack - Locked for update
19:28:08.000703 [debug]  BoxStack - Unlocked for update
19:28:08.000703 [debug]  Timers - Starting set timer 1

And here from the server log:

Quote
19:28:06.104000 [ERR]      RRProc - recvReq err 1

At more less the same time. (My windows pc and the vdr are not perfectly synchronized)
After the fix everything worked without problems.
I think that this occurs relatively seldom, but I am able to reproduce it with heavy channel switching.

Marten

@Lutz

Quote@Andreas: Your patch helps indeed, but it is not perfect.

Maybe Chris is right - and it would make sense to also handle it correctly at reads (some lines later in the file) - just check if read returns < 0 and errno == EINTR.
Sorry - no time for the code in the moment...

Regards
Andreas

@chris
Some additional note:
The effect of two requests at same time happens, because the mutex is unlocked after RR sleep until RR unsleep.
This is the way have interpreted the linux code and ported it to windows. If this is not the right behaviour of edSleepThisReceiver, please tell me how it should be done corretl,y

Marten

Hello Chris,
I recently started testing the new stuff. What I came about is the problem of zapping. I am not sure whether this problem occured just with the last cvs update of the dongle, but here it is what I came about.
When I switch from one channel to the other I am not able to switch again until the splash that shows the current epg data and connection stuff is hidden again. What happens instead is that the channel up and down stuff now navigates through th epg data in the splash. When I press ok to force the splash to go away and then switch up or down again it works again until the new channels splash info shows up.
As I wrote already I do not know whether this came up with the last cvs update, because I did not test heavy switching before.
One possible solution would be to disable epg scrolling at initial switching and enable epg scrolling the next time the splash is shown by pressing ok.

Moin,

this behaviour was also in the CVS June 5th.

BR,
Carsten.

I had a look at the code and found out that it is connected to systems with the old remote, as these remote controllers do not provide extra buttons for scrolling and channel switching. If you have a look at the vvideolivetv.cc you will see. As soon as the osd is visible with the epg data and stuff the buttons are mapped for scrolling but not to zapping. As soon as this osd is not visible anymore they are mapped to channel switching.
This might be the cause why it is only obvious to people with "old" mvps.
I wrote a little patch which suppresses scrolling while showing the epg osd while switching. Scrolling is then only activated if the osd is shown another time by pressing play or ok. I will test it tonight and if it works I will post it here.

Have a nice Friday 13th :-)

Will your patch differentiate between the old and the new remote?
Lutz

@Marten: Well spotted, thanks. I have applied your patch to cvs for queuing the incoming packets. (I thought I had made the client incapable of executing more than one RR at once, but actually I was thinking of the streaming instead - the client can currently only support one stream at once). I have also reworked it a little so that more packets can be queued while one is being processed. I think it should work fine, but will probably need some testing.

All:

I have attached another server build - the client is unchanged. It should fix the freeze when changing channels.

@Lutz Yes it will only apply to old remote controllers.

@Chris: I've tried the actual version with your dongle, and indeed it is much better, but occasionally freezes...
Was it just Marten's patch? Maybe I did something wrong while compiling before with his changes...

And I see a cosmetical issue: The writing of the OSD is touching the left side of the screen, the first number of the channel number is cut (also to see on 5:4 picture on 16:9 screen)

Regards
Lutz

Here is a dongle with the old remote buttons fixed for live tv. You can now only scroll the epg data if you pressed ok to show the epg.

Other issues to follow...

Thanks Chris, this deprecates the patch I have made. I did not have a look at your solution, but I think as it is pretty obvious it has  the same solutiuon. Thanks again and so far it looks great to me.

Please could anyone running the latest cvs files answer the poll or post about any remaining bugs in live tv, thanks.

Lutz: Could you supply a log from the client from a client crash? Thanks.

Running cvs (vdr 1.6.0, old remote) with no problems at all, though I don't use the media player so haven't tested it.

Hey Chris,
I am currently porting my vdr shutdown stuff to the new env. Is there any interest in applying it to the vomp. I also want to expand the functionallity to ask the user after pressing the power switch whether he wants to cancel shutdown of vdr with a timeout. In case cancel is not pressed a shutdown command is sent to vdr which simulates the power key press on vdr side. In case any thread blocks shutdown vdr will be shutdown as soon as all threads ended.
What currently exists is the shutdown stuff without asking the vomp user at power off. This means vdr shutdown is always sent when enabled. In case a other vomp is connected shutdown of vdr is blocked due to the active stuff you implented now.

Hi, could anyone still having problems with live TV freezing or crashing please post descriptions, client logs and optionally server logs. It's currently working for me and I don't know anything about any more live TV bugs.

Pompase: I don't know about it going in this version, but the good news is that I don't have any large codebase changes planned so updates and patches can be done quite quickly from now on. Even if it doesn't go in this version, I plan to spend most of my time for the next version integrating other people's work.

Chris

Just to note, I have no crashes yet with the new status.
So for me it is ok for me. Only a little fix in winmain and a little bugfix I have send to chris should go before release to cvs.

Marten

P.S: Sorry, for answering so late because first  I did not recognize Chris's post from 13 June, because the thread was too long

Up to now I do not have any crashes anymore with the vanilla version.

I still have freezes; I'll try to send a new log tonight...
Lutz

Bad news from me. Yesterday I was watching tv and flipping channels on my mvp and I got also a freeze. Only powercycling the mvp helped. (It has an old remote control). Unfortunetely I had not run logs on server or client side, so I am not able to guess the reason. The prebuffering progress bar was at zero, so the player have to be in prebuffering mode or before.
The crash happens very seldom (I flipped 20-30 and I got only one freeze) so that I am not able to reproduced it often enough too find the error.
At the moment I have no problems at the windows port with the fix in tcp I send to Chris. May be this is the reason?

Marten

Hi Chris,
its hard now to provoke the freeze, but still possible, and once in a while it happens just with one switch to the next channel while watching...
Here is my log...

Lutz

Hi,
I have now a client log from a crash.
Now, I had not enough time to go through, so I see no hints at the moment and I hope it is long enough to find the problem.
Btw, what is this SIGURG stuff, is it the remote?


Marten

I have analysed the log, and if you see

Quote08:18:59.772590 [debug]  67 VDR - RR 10
08:18:59.773564 [debug]  67 VDR - RR sleep
08:18:59.774649 [debug]  74 Command - PMFOS called
08:18:59.775565 [notice] 67 Core - Signal 23 received
08:18:59.776363 [debug]  67 Core - SIGURG caught
08:18:59.783700 [debug]  72 VDR - Rxd a response packet, requestID=336, len=5118
08:18:59.784722 [debug]  67 VDR - RR unsleep
08:18:59.786131 [debug]  67 VDR - Success got to end of getChannelSchedule

and SIGURG is the remote I think avvdr is right with his post:

Quotecould be the same problem I fixed in the 027 variant at vdr portal - interrupt (coming from key press) is handled as an error when waiting for data.
Currently I've got no time to test by my own, but the fix was in tcp.cc on the client side:
Just after select in readData (line 293 in current cvs)
#ifndef WIN32
      if (success < 1 && (errno == EINTR) )continue;
#else
      if (success < 1 && (WSAGetLastError() == WSAEINTR) ) continue;
#endif

Maybe someone can try this out. In theory this should also be handled for read but the chance for hitting a key when reading is much smaller then during select - so maybe not really necessary.

Regards
Andreas

But I think, it should also be fixed for read, since there -1 would be added to read bytes.

Marten

Hi,

my MVPs D3A connected via DLAN 200AVpro are working fine ... only one crash during the last 10 days.

But my MVPs (also D3A) connected via Linksys WAP54 (DD-WRT-Firmware) will crash in less then 1 minute ... LiveTV and playing recordings stop with "lost connection ..." and must be restarted by unplugging power.

EDIT: I'd tuned the connection between the AccessPoint(WAP54) and the Clients (WAP54) and had installed the new released DD-WRT-Firmware v24 on all WAP54s.
Now it is working  :D Thank you for this great software  :D

Any hints ?

Rumi

I have tried my idea with a selfcompiled dongle unfortunetely, the freezes are not gone on the mvp.

Marten

In case someone is interested, I am today debugging the vomp client crash.
I have localized it in edUnregister(TEMP_SINGLE_VDR_PR) called from StopStreaming.
I will trace it down more in detail... Any hints are appreciated.
Update:
It happens only when PlayerLiveTV switches from state 4 to state 2, it has not every time a segfault, but it happens so far  always in edUnregister after edr->nomorecalls and before for(i= ....

Update 2:
It is the line
pthread_cond_wait(&edr->cond, &mutex);

Marten

Hi Marten, I have just got back from another work trip, I will be looking at vomp later today I hope. Your efforts are much appreciated!

@Chris
May it be possible, that the cond variable of TEMP_SINGLE_VDR_PR was never initiallized and this causes an infinte block in pthread_cond_wait(&edr->cond, &mutex); ?

Marten

Ok, I will move the init of the condition variable to the receiver together with an proper destruction of the condition variable.
May be this is the reason, after testing a patch might follow.

Here is a replacement file for eventdispatcher.cc, after the changes I was not able to crash vomp on mvp anymore. (20 minutes
heavy channelswitching).
A dongle for testing will follow.

Marten

Here is a dongle for testing.
Can everybody with live tv freezes test it and report problems, please.

Marten

Attachment removed due to upcoming release!

Half an hour heavy switching, no freeze! Great work!
Lutz

Hi Marten,
could you consider to post an actual version of the windows client?
Lutz

@Lutz
May be at the weekend, it takes sometime to compile vomp on windows for release.(In the moment I have only debug versions.)

Marten

Using the the sourche Chris posted in Repley 48 and the vomp-dongle-mr-test posted by Marten. Compiled without probs and running stable on a mvp H4 and VDR 1.6 (eTobi) in Live TV.
Great Work! i like this solution so much!

--- edit ----
I manage to get it to freeze. After heavy zapping i was finally watching and after a few seconds the image froze and the sound also.
Unfortuinately no log was created, altough i think i set the option in the vomp.conf correctly.
Also i notice some artefacts sometimes in the picture that were not there with the older songle.

--------------

BTW, Its my first post on this forum, so hello all
Greetings from the Alps

@knutty: I think the log file is not created, you should create an empty file for it with write access to vdr...
Lutz

@knotty
I hate this message :-(
But maybe I did something with the linux stuff, I have changed, wrong. Since my knowledge of linux thread synchronization is limited, but may be Chris can check this.
To get an idea what is wrong, we need log of the client for this kind of error a server log would be useless.
Therefore log with telnet as root into your mvp. kill all vompclient processes (use ps and kill for this) and start "vompclient -d" and then the log is written into your telnet session, this log is the interesting one.
Please describe the freeze a little bit more in detail:
Was the programm schedule visible? Who full was the buffer box at the left side etc?
Network config might be helpful too.
This is necessary, that I will be able to reproduce it.

Marten

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.

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.

@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

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!

@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

@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

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?

@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

@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

@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

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.  ;D By buying an E1 and reselleing the D3A to a person that doesn't
use VOMP and is also happy now.

BR,
Carsten.

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

Quote from: Chris on June 10, 2008, 21:25:45
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.