v.1.5.33 dies unexpectedly when beginning playing recording on PCH

[BrettB]

If you haven't played any files since then can I also see what is in /tmp/dumpts.txt on the PCH?

Martin

Martin,

I'm still having the original problem from this thread where mvpmcx2/npvr dies unexpectedly when first trying to play a recording. It just now happended to me a couple of times. The 2nd time, I used putty and got the output log and the dumpts.txt from the PCH before rebooting. See the attached logs.

In both of the cases which just happened tonight, the recording that I had just previously watched was NOT one that had the weird channel change at the end. So I think that the problems may be unrelated.

Is there any sort of additonal error handling that you could add on the mvpmcx2 side to make it more gracefully "exit". (Something that would take the PCH back to gaya?) Having to go power off the PCH and wait for it to reboot every time this happens is a pain.

- Brett

[sub]

I cant see any obvious sign of problems in the NPVR side of things. I'd probably need to get Martin to give me an interpretation of what mvpmcx2 or the PCH is unhappy about.

[mvallevand]

There are two problems, the first is the merged HDHR recordings which I can't help with and also the the crashes.

Brett I can't help with extra logging because the logs I am not seeing are on the server side, I am expecting a SendIncrementalFrameDataWithAlpha message. Looking at your offsets you are breaking rules with 2x36+652 =724 try dropping 652 to 648.

Martin

[sub]

There are two problems, the first is the merged HDHR recordings which I can't help with and also the the crashes.

I'm aware of that one - but this is apparently in the post padding, so I dont think its an issue here. I've downloaded his sample file, and intend to write some software to analyse it.

His issue happens at the beginning of playback, so it sounds like there is something else mvpmcx2 or the PCH doesnt like.

Brett I can't help with extra logging because the logs I am not seeing are on the server side, I am expecting a SendIncrementalFrameDataWithAlpha message. Looking at your offsets you are breaking rules with 2x36+652 =724 try dropping 652 to 648.

[BrettB]

Brett I can't help with extra logging because the logs I am not seeing are on the server side, I am expecting a SendIncrementalFrameDataWithAlpha message. Looking at your offsets you are breaking rules with 2x36+652 =724 try dropping 652 to 648.
Martin

Martin,

I'm not sure what you mean by "the logs I am not seeing are on the server side". And I think that you mean I should change my MVPHeight from 652 to 648. Is that correct? I just made that change and restarted mvpmcx2 on the PCH.

If/when the problem occurs again, is there something else that I should collect to assist and troubleshooting? (Like some other file from the PCH or elsewhere on the npvr server)

- Brett

[BrettB]

Here's another set of logs since the problem just happened again. (With the changed MVPHeight parameter.)

Also, you both probably saw this before, but I hadn't noticed it. The web.log file has several of these errors when the problems are happening:

Code:

[CODE]2010-11-05 20:55:30.957    [ERROR][12]    Unexpected error streaming file: System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   at Cassini.Request.StreamFile()
[/CODE]

EDIT: After rebooting and restarting playing this recording (The Whole Truth), I noticed that the .edl file has a commercial at the beginning. I'm not sure why becuase my comskip.ini file is supposed to have commercials at the beginning "disabled." Maybe it's a clue...

[BrettB]

And another possible clue:

When I just watched the recording all the way through, it didn't end and go back to the recording screen. Instead, it just kept playing by starting over at the beginning.

EDIT: I attached the logs showing the "restart at the beginning" just in case it is helpful at any point.

[mvallevand]

Sorry Brett I don't see a thing in the logs that can help me and I don't know where to even take this. The comskip skip at the beginning if there was one, didn't get send.

The restart is simply how mvpmcx2 is reacting to bad data. I probably should use timing info to see if I can seek over the problem.

Finally the error in the web.log are normal, it will occur every time you skip or the file ends.

Martin

[BrettB]

And another possible clue:

When I just watched the recording all the way through, it didn't end and go back to the recording screen. Instead, it just kept playing by starting over at the beginning.

EDIT: I attached the logs showing the "restart at the beginning" just in case it is helpful at any point.

I guess you can't edit and add an attachment. So here are the logs in a new post.

[mvallevand]

Sorry Brett again nothing stands out, the sockets just seem to be closing. Are you using the Default skin if not try using and also try removing the Weather plugin to get you close to my setup, since I cannot duplicate what you are experiencing. The logs don't show anything close to a server request that have cause problems in the past.

Martin