TVServer stops 'serving'...? (1 Viewer)

[mm1352000]

So, the logs show that MP client / tsreader is trying to open live3-0.ts.tsbuffer1.ts at 6:54pm, which is odd since I allow for several buffer files to be open, so I'm not sure why it would be reusing the first buffer file again so soon.

That is normal. TsWriter doesn't use more than the minimum number of files unless it has to (ie. it has to because somebody is still timeshifting in that file).

Regardless, the tsbuffer1.ts file shows a timestamp of 6:14pm, so to me, it looks like this is an old file - unless when TVServer/tswriter reuses a file, it doesn't update the creation date/time?

I don't know about that.

Attached is a screenshot of my timeshifting settings from within the TV Server config tool. I see that I have the minimum number of files set to 3.... What does that mean in regards to my issue - should I attempt increasing the minimum number to something higher as a test?

As above, TsWriter will create 3 timeshift files (as and when necessary) in normal live TV viewing. If you pause for long enough, according to your settings TsWriter will create up to 100 timeshift files. Increasing the minimum will just mean you have a longer back buffer. It doesn't help to debug this issue.

What would help is when you get into this situation, copy the timeshift file that TsReader is claiming it can't open (ie. in this case, the first one) and attempt to open that copy in VLC. Most (but not all) buffer files are playable in that way. If it works, you'll know for certain from the content whether TsWriter successfully reuses the file (ie. TsReader/UNC problem) or not (ie. TsWriter problem).

The other thing you can...
I checked out the code with an eye to seeing where I'd need to put debug in for you. I found that debug is already present. It just isn't logged. To view the debug, use DbgView:
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx

Doesn't require install. Just run it with admin privileges. In the capture menu, tick everything except log boot and enable verbose kernel output. If you do it correctly, an entry should show each time TsWriter creates or reuses files.

 

[CanadianEh]

Thanks, mm. I have the DbgView open and logging to it's console. I do see that it is spewing a lot of data - any suggestions on how best to filter this 'capture' when the issue reoccurs to find the pertinent data?

The thought that the "recycled" .ts file may be 'locked' by another process did cross my mind, as well - I don't have any other MP clients running in the house at this time, so that wouldn't be the cause of a lock. I've already double-checked that the entire E: drive is excluded from real-time AV scanning.

Anyway, I will try opening the file in VLC the next time I see a 'freeze'. Perhaps if this looks to be a file lock-type of issue, I could try filemon as well in the future.

Thanks again - I'll post more info the next time this occurs.

 

[mm1352000]

Thanks, mm. I have the DbgView open and logging to it's console. I do see that it is spewing a lot of data - any suggestions on how best to filter this 'capture' when the issue reoccurs to find the pertinent data?

Hmmm, the spew must be coming from other applications you have open. TV Server doesn't write anything except file create/reuse entries. Either close all other applications... or when I get home I'll run the test myself and try to get you a filter that will isolate to the TsWriter entries.

The thought that the "recycled" .ts file may be 'locked' by another process did cross my mind, as well - I don't have any other MP clients running in the house at this time, so that wouldn't be the cause of a lock. I've already double-checked that the entire E: drive is excluded from real-time AV scanning.

As mentioned previously, my working theory is that this is the familiar SMB share access issue. I'd expect TsWriter to complain if it couldn't open a file for writing due to locking.

@HomeY has been dealing with a related issue recently. He found that disabling SMB v2 on his client helped him. Maybe you could try the same:
http://support.microsoft.com/kb/2696547

Anyway, I will try opening the file in VLC the next time I see a 'freeze'. Perhaps if this looks to be a file lock-type of issue, I could try filemon as well in the future.

Great, thanks.

 

[CanadianEh]

I'm attaching a quick screenshot - the data it is capturing appears to be a constant stream of what you're seeing in this screenshot.

I can certainly try disabling SMB v2 - Server, client-side, or both in this case?

 

[mm1352000]

I'm attaching a quick screenshot - the data it is capturing appears to be a constant stream of what you're seeing in this screenshot.

That might be coming from the HD-PVR driver... or do you have the Hauppauge WinTV software installed, and if so, have you disabled their TV service?

I can certainly try disabling SMB v2 - Server, client-side, or both in this case?

A quick read of the thread suggests client side only, but I'm not sure that it matters. @HomeY might be able to say more later (he'll still be in bed at the moment as he is based in Europe).

 

[CanadianEh]

Ha...you were correct, there was a HauppaugeTVServer service running in the background that I wasn't aware of. I've stopped and disabled it. It's now logging much cleaner in DbgView, and I can now actually see the files being created. I'll let this run tonight / tomorrow morning before shutting off SMB v2/v3.

 

[HomeY]

HomeY might be able to say more later (he'll still be in bed at the moment as he is based in Europe).

Morning Client only is sufficient.

 

[CanadianEh]

Thank you guys.

So, before making changes, I continued letting the DbgView app capture the next 'freeze', which occurred at 8:31pm tonight. I was able to determine the following:

- DbgView showed that live11-0.ts.tsbuffer3.ts was 'reused' at 8:31pm, the exact time of the client freeze.
- The timestamp for the creation of the .TS file is *not* updated when reused - the timestamp was from around 7:20pm
- I was able to copy the xxxxTsbuffer3.ts file and open it with VLC, showing that the file was indeed updated and contained the tv program from 8:31pm and onward.


So, mm - so far you've been correct with everything

I have gone ahead and made the registry change to disable SMB2/3 on the MediaPortal Client PC (only the client pc, per HomeY's comment), and rebooted the client PC. I have the client now streaming again in Debug mode, along with DbgView still running on the server, just in case another issue occurs.

I am hopeful you have solved this issue for me - I'll check in again regardless to let you know the results.

Thank you!![DOUBLEPOST=1389233178][/DOUBLEPOST]BTW, I found this other forum post, which sounds exactly like the issue here. It does offer another potential solution, but I'm fine with using SMB1 for now, if this does fix the issue.

http://stackoverflow.com/questions/...newly-created-files-arent-visible-for-some-pe

 

[CanadianEh]

Well, unfortunately, the issue happened again last night - at 9:37pm. I'm attaching logs ang a screenshot of DbgView. I wasn't able to do any tests with the files in the Timeshift folder at that time, but I think we already gathered the info we needed from within there above.

Now - the odd thing... I didn;t touch the client PC this time - I just left it "frozen", and when it came time to roll to the next buffer file, the client automatically started playing the new file, as if nothing ever was wrong. One note - I gathered the logs today, so you'll need to look at the tsreader.bak file since it occurred before midnight.

Now, after setting my client PC to only use SMB1, should I go ahead and make the same registry change on the server, just in case it's trying to re-negotiate or something here? Any other thoughts on how to debug this?

Thanks!

 

[HomeY]

Now, after setting my client PC to only use SMB1, should I go ahead and make the same registry change on the server, just in case it's trying to re-negotiate or something here?

Nope, the Client change should be sufficient.