Testers Needed!

[Lutz]

@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

[avvdr]

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

[Chris]

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

[Lutz]

@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

[MartenR]

@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

[Lutz]

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

Lutz

[Chris]

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

Thanks

[Lutz]

@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

[MartenR]

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

19: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:

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

[avvdr]

@Lutz

@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

[MartenR]

@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

[pompase]

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.

[carsten]

Moin,

this behaviour was also in the CVS June 5th.

BR,
Carsten.

[pompase]

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 :-)

[Lutz]

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