Remote clients knocking each other off their tuners

[sub]

It looks like the latest release is Sep 16 2011. I got it from here: http://www.nextpvr.com/nwiki/pmwiki.php?...order#toc1. Is there a newer version?

I was referring to the discussion Martin and I were having above, where it was sounding like the Network Recorder was never denying a request to start live tv, and the Network Recorder would need to be changed to fix that. (ie, a change not yet made)

[mvallevand]

Sub's meant I probably need to update it, and I probably do, but right now I don't know what needs changing because I thought the calls were on one tuner.

Martin

[crutonius]

Also, the when computer b knocks out computer a then computer a has a message about the tuner being needed for a recording.

[crutonius]

Sub's meant I probably need to update it, and I probably do, but right now I don't know what needs changing because I thought the calls were on one tuner.

Martin

Oh. Is it open source? I might be able to help.

When NPVR starts to use one of these tuners it seems like NPVR on the client and server ends freezes while this is going on. A hefty delay seems to be necessary in NetworkRecorder.xml to get these tuners to function reliably. Maybe the thread that services the requests from the client is held up too long by the request of the other client to use a tuner?

[mvallevand]

During your dead time of 8000ms not much is happening on that thread and your logs show it come out cleanly. The API doesn't have a yield function and sub doesn't recommend Application.DoEvents() so I didn't want to put one in NRecorder

Code:

int steps = delay / 1000 * 2;
                for (int i = 0; i < steps; i++)
                {
                    System.Threading.Thread.Sleep(500);
                }

Did you try with 5000 since using the donator version of SageDCT?

I still need sub's comment on my post with the analysis on why he sends the stop to me.

Martin

[sub]

I still need sub's comment on my post with the analysis on why he sends the stop to me.

It looks like one of the clients hasn't requested a renewal in a timely fashion.

Code:

2013-10-27 15:54:20.875    [ERROR][9]    Live stream expired without renewal. (handle:1603E8)

[crutonius]

Yes. I'm currently at 4000. I seem to have problems with the tuners actualy starting if I go lower than that.

[mvallevand]

Yes he posted the logs for the client

Code:

2013-10-27 15:53:38.917    [DEBUG][1]    Updating OSD.
2013-10-27 15:53:42.549    [DEBUG][1]    Frame Render Rate=17.4364032745361
2013-10-27 15:53:42.909    [DEBUG][1]    Hiding OSD.
2013-10-27 15:53:45.646    [DEBUG][1]    Client about to request renewal of handle: 1603E8
2013-10-27 15:53:55.692    [DEBUG][1]    Client about to request renewal of handle: 1603E8
2013-10-27 15:54:15.386    [DEBUG][1]    Stopping graph@1

There's likely blocking in NRecorder but I don't know if I can avoid it in NRecorder. The streaming thread I create shows it growing.

Martin

[crutonius]

Here's a new piece of information that might be useful. It seems to work if the second client is XBMC.

[mvallevand]

Yes that info ties into my post just above, something in the client seems to block live tv. I added the Application.DoEvents into that loop to see if frees the thread enough to let the client through. Does this help? Replace the files and restart the recording service, I don't think clients need to be updated. Again this approach is not recommend by sub so consider it experimental.

Martin