TV Client Live TV Freeze (1 Viewer)

[mm1352000]

Wow, now that is exhaustive testing! I really appreciate your thoroughness and how clean the logs are. Makes my life really easy, so thank you

I can clearly see that the TV stream is stopped intensionally. Of course I don't mean that you are intensionally stopping TV. Something else is driving this. Below is an excerpt from MediaPortal.log at the critcal time in the Intervideo Non CSS Decoders For Hauppauge test:

2010-12-15 16:10:14.132932 [Info.][MPMain(1)]: Added filter: InterVideo NonCSS Audio Decoder for Hauppauge to graph
2010-12-15 16:10:14.133932 [Info.][MPMain(1)]: TSReaderPlayer: Render TsReader outputs
2010-12-15 16:10:14.251938 [Info.][MPMain(1)]: TSReaderPlayer: OnInitialized
2010-12-15 16:10:14.251938 [Info.][MPMain(1)]: TSReaderPlayer: position:-0.158999994397163, duration:6.6080002784729
2010-12-15 16:10:14.252939 [Info.][MPMain(1)]: g_Player.OnStarted() D:\Temp\live2-0.ts.tsbuffer media:TV
2010-12-15 16:10:14.260939 [Warn.][MPMain(1)]: tvhome:startplay. Phase 2 - 638 ms - Done starting g_Player.Play()
2010-12-15 16:10:14.269940 [Warn.][MPMain(1)]: TVHome.OnClicked(): Total Time - 9795 ms
2010-12-15 16:10:14.322943 [Info.][MPMain(1)]: TvNotify:LoadNotifies
2010-12-15 16:10:14.725966 [Info.][(13)]: PlaneScene: video WxH : 720x576
2010-12-15 16:10:14.726966 [Info.][(13)]: PlaneScene: screen WxH : 350x251
2010-12-15 16:10:20.150276 [Info.][MPMain(1)]: TvNotify: 0 notifies
2010-12-15 16:11:46.625222 [Info.][MPMain(1)]: Main: OnResizeEnd
2010-12-15 16:11:49.117364 [Info.][MPMain(1)]: g_Player.OnStopped()
2010-12-15 16:11:49.122365 [Info.][MPMain(1)]: TVHome:turn tv off
2010-12-15 16:11:49.596392 [Info.][MPMain(1)]: TvRecorded:OnPlayRecordingBackStopped TV D:\Temp\live2-0.ts.tsbuffer
2010-12-15 16:11:49.598392 [Info.][MPMain(1)]: TSReaderPlayer: cleanup DShow graph False

So it looks like the Intervideo codec lasted roughly 1:30. Notice the "Main: OnResizeEnd"? I *think* that is pointing to the problem, however my specialty is really in TV Server not MediaPortal (I'm still learning ). I'm going to have to resort to looking at the code to determine why that resize would be happening...

Could you tell me: are you running in windowed mode, or full screen?

From these tests can I rule out it being a driver/hardware issue as the card seems to be doing it's job and the time frame that Live TV/Recorded TV works seems to be dependant on what codec is used?

I'd have to agree...

I did try and use the WinTV application it's self to determine if the card did fail after a period of time, but I cannot get the application to work and show me my SVideo/RCA input stream which I feel maybe due to having a 250 and 300 card in the same machine (the application possibly cannot handle two cards using the same drivers?).

An excellent idea. Would have definitively eliminated a hardware issue - shame it didn't work
Since your cards have hardware encoders they should be pretty reliable. At least more reliable tuners than need software encoders anyway...

One question I also have is that when you use the preview button within the TV server, does that make a direct connection to the hardware so to speak or does it still stick the MPEG 2 Transport Stream in the middle before it shows you what is being displayed on the channel as if it does not use the Transport Stream I can use it to rule out it being hardware/driver related?

No, the tuner graph (the connections from the tuner, through crossbar - the tuner/s-video/composite connection matrix - encoders, etc. to timeshifting file) is the same whether in TV server preview mode or MediaPortal. It always uses a timeshift file (I guess this is what you mean by "transport stream"). I think there is a difference in the playback side (meaning: the playback of the timeshift file or stream) in that the codecs used for preview are the codecs with the highest merit (think: priority) in the system, rather than the ones configured in MediaPortal configuration. Hope that gives you some insight...

Just to recap, I'm pretty baffled by the resize thing. I no longer think providing a debug build of TV server will help us as the cause chain seems to lead back to MediaPortal rather than TV Server. I hope that is okay with you? It will take me time to find out what is happening. I ask for your patience...

Thanks once again for the excellent logs!

 

[spar1grep]

Hi mm1352000

No problems about the logs I do undestand how important generating a decent test is and reducing the possibility of mis-diagnosis because of noise. Yes I was running the MP client in window mode as normally I run it full screen but in order to capture the log files at the moment the TV server froze I reconfigured it to run in a window. In relation to the Main:OnResizeEnd could that event be generated by the MP Client window loosing focus and then me clicking on the windowed MP Client titlebar and moving the window as I had about five different windows open on the desktop and had to keep jumping between them to copy the files etc. You are right about your TS buffer reference I was referring to the timeshifting file when using the term transport stream.

As you are pretty certain that something it telling MP to stop the stream and there is a difference time period before the LiveTV freezes dependant on the codec being used (the time period remains pretty consistent if I repeat the tests using the same codec over and over) to read the timeshifitng file, does the decoder codec make a difference to the amount of time that can be fitted inside say for example a 1GB timeshift buffer file or does the amount of time that fits into the timeshifiting file always remain constant? My thinking is that maybe when the next .TS file is supposed to be created and the MP Client is supposed to goto to the next .TS file in the sequence as configured in the TV Server timshifting section that something goes wrong at that point? I did read up on the Wiki article about the transport stream buffer but I could not figure out if the decoder used has a impact on it?

Regards.

Gary

 

[mm1352000]

Hi again

To briefly answer your questions before I get to bed:

In relation to the Main:OnResizeEnd could that event be generated by the MP Client window loosing focus and then me clicking on the windowed MP Client titlebar and moving the window as I had about five different windows open on the desktop and had to keep jumping between them to copy the files etc.

I don't think so. Not unless you accidentally resize the window every time, and that is very unlikely. Not only that, you've reported that the same thing happens when you're in full screen mode...

As you are pretty certain that something it telling MP to stop the stream and there is a difference time period before the LiveTV freezes dependant on the codec being used (the time period remains pretty consistent if I repeat the tests using the same codec over and over) to read the timeshifitng file, does the decoder codec make a difference to the amount of time that can be fitted inside say for example a 1GB timeshift buffer file or does the amount of time that fits into the timeshifiting file always remain constant? My thinking is that maybe when the next .TS file is supposed to be created and the MP Client is supposed to goto to the next .TS file in the sequence as configured in the TV Server timshifting section that something goes wrong at that point? I did read up on the Wiki article about the transport stream buffer but I could not figure out if the decoder used has a impact on it?

The decoder that is used has no impact on the timeshift file size. They're generally set at around 250MB, so you're unlikely to hit that limit in 1:30. I will say that the decoder variation is strange. The error is the same in each case though. Here is the output for the Microsoft decoder:

2010-12-15 16:51:32.038660 [Info.][MPMain(1)]: Added filter: Microsoft DTV-DVD Video Decoder to graph
2010-12-15 16:51:32.041660 [Info.][MPMain(1)]: Added filter: Microsoft DTV-DVD Audio Decoder to graph
2010-12-15 16:51:32.041660 [Info.][MPMain(1)]: TSReaderPlayer: Render TsReader outputs
2010-12-15 16:51:32.356678 [Info.][MPMain(1)]: TSReaderPlayer: OnInitialized
2010-12-15 16:51:32.357678 [Info.][MPMain(1)]: TSReaderPlayer: position:-0.158999994397163, duration:6.79200029373169
2010-12-15 16:51:32.358678 [Info.][MPMain(1)]: g_Player.OnStarted() D:\Temp\live2-0.ts.tsbuffer media:TV
2010-12-15 16:51:32.371679 [Warn.][MPMain(1)]: tvhome:startplay. Phase 2 - 676 ms - Done starting g_Player.Play()
2010-12-15 16:51:32.382679 [Warn.][MPMain(1)]: TVHome.OnClicked(): Total Time - 9464 ms
2010-12-15 16:51:32.435682 [Info.][MPMain(1)]: TvNotify:LoadNotifies
2010-12-15 16:51:32.869707 [Info.][(14)]: PlaneScene: video WxH : 720x576
2010-12-15 16:51:32.870707 [Info.][(14)]: PlaneScene: screen WxH : 350x251
2010-12-15 16:51:37.742986 [Info.][MPMain(1)]: TvNotify: 0 notifies
2010-12-15 16:55:59.160938 [Info.][MPMain(1)]: Main: OnResizeEnd

Same OnResizeEnd. Approximately 4:30 of timeshifting, exactly like you said. Strange!

There is one other thing that I noticed in the TV Server logs that I forgot to mention earlier:

2010-12-15 16:51:23.917195 [(10)]: Set new video format to: PAL_I
2010-12-15 16:51:23.920195 [(10)]: Set VideoProcAmp - Brightness to value: 136
2010-12-15 16:51:23.922196 [(10)]: Set VideoProcAmp - Contrast to value: 64
2010-12-15 16:51:23.925196 [(10)]: SetFrameRate: FAILED no format returned

That could be important because if the frame rate isn't right then different codecs could have different behaviour/tollerance. Are you able to check whether your card supports setting the frame rate in TV Server configuration?

1. Open TV Server configuration.
2. Expand the "TV Servers" section.
3. Expand your HTPC "TVServer".
4. Select one of your WinTV tuners.
5. Go to the second tab.
6. Can you set the video format, frame rate and resolution? Are any of them unselected?

Off to bed now.

 

[spar1grep]

I didnt realise you live in NZ, you lucky begger!! My dream is to emigrate to NZ/OZ, you must have a mean setup for MP over there as I get the feeling you can get a lot more integrated with Sat cards in NZ then you can in the UK (with BSkyB's and Vigrin Media's dominance in the UK satellite/cable market we cannot use sat or cable TV cards with CAM modules which was is my ideal setup rather then a cruddy sVideo connection and LM Gestion for IR control of the STB).

I checked the settings tab for the only enabled card I have and the Video Standard is set to PAL_I, frame rate is 25 fps (PAL/Secam) and the frame size is 720x576 PAL/SECAM ITU-601 D1 (recommended), I can change these settings to the other US settings NTSC 29fps etc.

 

[tourettes]

I'm 99% sure that the issue is completely related to the "Main: OnResizeEnd". It shouldn't be caused by codecs or the tvs erver side at all. Somehow the MP gets resize event.

 

[spar1grep]

Hello tourettes,

Could the Main: OnResizeEnd event be instigated by the graphics driver doing something it should not?

Cheers.

Gary.

 

[spar1grep]

Hello All,

More testing tonight but not really any progress I can confirm that the tsbuffer file only ever has in it the same amount of video that was displayed before the freeze occurred. I also am very very certain that the Main: OnResize recorded in the debug log file for the MP Client is not related to the problem as my testing has shown this event is only logged if the MP client is running in a Window and the window looses focus and when you click on the window title bar to get the focus back onto the MP Client window and move the window then this event is logged. As during my testing I was doing the event Main:OnResize event is not logged in the Realtime Capture logs I included in the zip files which were copies taken of the log files at the exact point the Live TV would freeze.

Not much more to report still cannot get anything else to work to determine if the drivers for the tuner cards are having an effect on causing the stream to fail or if it is the MP TV server. This all started out because the reliable HTPC I had MP running sweet on (a XP Pro based PC) suffered a integrated NIC failure so I thought why not replace it with my beast PC with Windows 7 and all the bells and whistles. Should never have bothered and just spent the £10 for a PCI based NIC adapter grrrrr!

 

[tourettes]

Hello All,

More testing tonight but not really any progress I can confirm that the tsbuffer file only ever has in it the same amount of video that was displayed before the freeze occurred. I also am very very certain that the Main: OnResize recorded in the debug log file for the MP Client is not related to the problem as my testing has shown this event is only logged if the MP client is running in a Window and the window looses focus and when you click on the window title bar to get the focus back onto the MP Client window and move the window then this event is logged. As during my testing I was doing the event Main:OnResize event is not logged in the Realtime Capture logs I included in the zip files which were copies taken of the log files at the exact point the Live TV would freeze.

I agree that the resize event shouldn't be the real reason after looking at the live logs in more detail (that was the 1% case ).

There is just nothing that indicates that the playback would have been stopped. Is this live tv only issue? Does it help if you start live tv and the pause it for 15 seconds before continuing? Also does the freeze go away if you skep back for 15 seconds after the freeze happens? Does it help if you change the audio renderer to something else in tv config?

 

[spar1grep]

Hello All,

I never found a solution to this so I went back to my original hardware and Windows XP, using the same drivers for the 350 WinTV card and everything is again working as it should.

As there is nothing being reported in the logs I can only surmise it is something outside of MP that was causing the problem, either OS or driver related.

Cheers for all your help anyway, looks like I will be sticking with XP until MP dont support it anymore!

Merry Christmas All!

 

[mm1352000]

Thanks for reporting back. Only sorry you were forced to resort to moving back to XP...

Merry Christmas to you too