Project

General

Profile

Bug #1844

Stream client stops recieving data after CWC errors

Added by Claus Holbech almost 11 years ago. Updated over 10 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
Descrambling
Target version:
-
Start date:
2013-11-26
Due date:
% Done:

100%

Estimated time:
Found in version:
3.5.245
Affected Versions:

Description

Running VLC streams for a longer period of time on an encrypted channel will result in client not receiving any data if the CWC client fails to get correct keys for while.
The client stream then ends in a deadlock, where it is not able to recover from this issue, even when CWC receives valid keys again.

Starting a new stream to the same channel will end with same issue (It connects fine, but receives no data).
On the status page the client is active, but the Bandwidth is at 0.

Stopping all connections to the channel, and waiting for them to clear from the status page, will solve the issue, and it is now possible to start the stream from the channel again.

History

#1

Updated by Claus Holbech almost 11 years ago

The same issues is in also version 3.5.243

#2

Updated by wms geek almost 11 years ago

Same issue with the latest build

#3

Updated by Claus Holbech almost 11 years ago

I can see that I am not the only with his issue, I was beginning to think that is was just my setup that was the problem.

I must say that it is the best project in its class I have seen, in some point it even exceeds professional solutions.

I have not yet donated to the project, which I should have done, but this error has held me back.
So, if this bug can be fixed, i have decided to donate 500€ to the project.

Hope to hear from you soon..

Claus

#4

Updated by Adam Sutton almost 11 years ago

This is actually reasonably well understood problem. Just no one has had time to fully investigate the potential side-effects of making any changes.

For reasons I do not know, it appears that a hard limit of 2 NOKs was put on the CWC code. After this is simply fails to do anything until you completely stop the service and restart.

Clearly not a good thing, and it's caught me out before, but I've since switched to capmt and so not given it much thought since.

Adam

#5

Updated by Adam Sutton almost 11 years ago

As a quick and dirty hack you could try removing these 2 lines from src/descrambler/cwc.c:

if (es->es_nok > 2)
break; /* too many NOK responses in a row */

I think that will keep it sending requests, and as long as it eventually gets a valid one it will remove the block and continue. Though I've never tested this myself.

Adam

#6

Updated by Claus Holbech almost 11 years ago

Hi Adam

Thank for your suggestion, i will try that, and get back to you.

Another quite annoying issue, is that maapped channels gets swapped around after restart of Tvheadend.. Is there a fix for that too?..

Claus

#7

Updated by danny skjodt almost 11 years ago

Nice to hear this is going to be fixed, ive had this problem aswell, about the channel swapping, you say its id is changing ? ive found that the best fix for that is to give your channels numbers instead of all 0, for some reason they will keep their id then.

#8

Updated by Adam Sutton almost 11 years ago

  • Status changed from New to Accepted
#9

Updated by danny skjodt almost 11 years ago

I can confirm that removing the above 2 lines indeed works.

#10

Updated by Adam Sutton over 10 years ago

  • Status changed from Accepted to Fixed
  • % Done changed from 0 to 100

Applied in changeset commit:tvheadend|dd8d66370f1bdc6fad402278d1ba25de59fb5746.

Also available in: Atom PDF