Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve reliability on slow internet connections #3

Closed
nickb937 opened this issue Sep 3, 2013 · 8 comments
Closed

Improve reliability on slow internet connections #3

nickb937 opened this issue Sep 3, 2013 · 8 comments

Comments

@nickb937
Copy link

nickb937 commented Sep 3, 2013

The following patch will reduce glitching by increasing the tolerances that the application will allow for delayed key response. I've been using this for 12 months on a 3G/GPRS connection with positive results. I would think it would be of benefit to other network connection types because there will always be occasions where ECM replies take 700ms or 1000ms to come back, due to unforseen network congestion.

diff --git a/device.c b/device.c
index 2c1a5ec..5535d76 100644
--- a/device.c
+++ b/device.c
@@ -978,10 +978,10 @@ bool cScCiAdapter::Assign(cDevice *Device, bool Query)

 #define MAX_CSA_PIDS 8192
 #define MAX_CSA_IDX  16
-#define MAX_STALL_MS 70
+#define MAX_STALL_MS 140

 #define MAX_REL_WAIT 100 // time to wait if key in used on set
-#define MAX_KEY_WAIT 500 // time to wait if key not ready on change
+#define MAX_KEY_WAIT 2000 // time to wait if key not ready on change

 #define FL_EVEN_GOOD 1
 #define FL_ODD_GOOD  2
@bas-t
Copy link
Owner

bas-t commented Sep 3, 2013

I have to ask: is this meant to make it possible to use cardsharing over the internet?

@nickb937
Copy link
Author

nickb937 commented Sep 3, 2013

That's already possible. This just makes it work better.

@bas-t
Copy link
Owner

bas-t commented Sep 3, 2013

Where I live, the use of FFdecsawrapper is legal, but not wihen using internet cardsharing servers.
I don't want to give our government a good reason to make it illegal here too, so I probably should reduce these settings. Not increase them. I'll think about it.

@bas-t bas-t closed this as completed Sep 3, 2013
@bas-t bas-t reopened this Sep 3, 2013
@bas-t
Copy link
Owner

bas-t commented Sep 3, 2013

On the other hand, it might make it possible to plan like 6 or even more recordings in MythTV starting at the exact same time. ATM I'm stuck with max 4.
That would be a valid reason to use your diff.
Have to test this first.

@ghost ghost assigned bas-t Sep 3, 2013
@bas-t
Copy link
Owner

bas-t commented Sep 3, 2013

I could not detect any improvement regarding the 'start many recordings beginning at the exact same time' issue.
Prove me wrong.

@nickb937
Copy link
Author

nickb937 commented Sep 5, 2013

Have you tried running one process for each adapter rather than having one process handle all adapters?

@bas-t
Copy link
Owner

bas-t commented Sep 5, 2013

No, I did not.
I'll try this when I have time.

@bas-t
Copy link
Owner

bas-t commented Sep 6, 2013

Running one process for each adapter takes way to much cpu cycles (like almost 3 times to much) when recording more then 1 show on the same adapter.
I'm not going to dive into this anytime soon, so I'm closing this now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants