Problems with Live TV

[tcmy95]

Here you go Martin.

I noticed that once the freeze has occured GBPVR still has the stream open. I can't remember whether mdapi was still running though but I will check next time it happens.

I have included the Mdapi logs aswell

Thanks

Ian

[sub]

If its only happening when watching encrypted channels, then its probably something timing related with multidec taking too long to start producing data when the file change time happens.

Does a new file get create in your live tv buffer directory when this happens? Does the file grow beyond zero bytes?

[tcmy95]

Does a new file get create in your live tv buffer directory when this happens? Does the file grow beyond zero bytes?

Not certain. Does a new TS get created in the temp dir when a new program starts? The screen has just flickered black on me then I got the popcorn buffer screen and then it went back to the channel but this was right in the middle of adverts switching between programs and a new file was created. This happened on a un-encrypted channel.

It did the same thing on an encrypted channel earlier and then about 5 mins later the picture just froze with continuing audio and then silence. It always requires a reboot of the NMT to be able to play anything including Music, Videos and live TV.

Sorry for rambling Sub.

Ian

[mvallevand]

Here is the crash that I don't understand in the earlier logs.

Code:

2008-10-30 22:00:28.395    VERBOSE    [6]    RenewLease: 1
2008-10-30 22:00:28.458    ERROR    [6]    handleMVPConnection() exception: Object reference not set to an instance of an object.
2008-10-30 22:00:28.458    VERBOSE    [6]    
Server stack trace:
   at NativeUtilities.BDARecorder.StartNewFile(String filename)
   at GBPVR.Backend.Common.BDARecordingSource.startNewFile(String filename, ChannelTuning channelTuning)
   at GBPVR.RecordingService.x93f60a55016d55c4.xb8da78bd4ee79bb8(Int32 xeba3e20435eb0e32, Boolean x03f525c749695de4, String& x8b1d9e3189e6e73d, Int32& x73dd716c35ea457b)
   at GBPVR.RecordingService.RecordingRemote.xb8da78bd4ee79bb8(Int32 xeba3e20435eb0e32, Boolean x03f525c749695de4, String& x8b1d9e3189e6e73d, Int32& x73dd716c35ea457b)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at GBPVR.Backend.Common.IRecordingService.xb8da78bd4ee79bb8(Int32 xeba3e20435eb0e32, Boolean x03f525c749695de4, String& x8b1d9e3189e6e73d, Int32& x73dd716c35ea457b)
   at GBPVR.Backend.Common.x396614b3dae3b1da.xb8da78bd4ee79bb8(Boolean x03f525c749695de4, String& xea99cc8af6f9bef1, Programme& x5d1dc8495c0908a9)
   at GBPVRX2.Players.xbe83d16b02243330.xbeedcf1cf26c02d4()
   at GBPVRX2.Players.xbe83d16b02243330.GetRenderList()
   at GBPVRX2.MVP.x3ca133dee7547455.x19e39e0d5aeedfb8()
   at GBPVRX2.MVP.x3ca133dee7547455.x3d75adb3418c5c9e()
   at GBPVRX2.MVP.x3ca133dee7547455.xd3faf5962405de4e()
2008-10-30 22:00:28.474    VERBOSE    [6]    MVPSendStopRequest()
2008-10-30 22:00:28.974    VERBOSE    [6]    EnableScreenSaver()

Martin

[tcmy95]

If its only happening when watching encrypted channels, then its probably something timing related with multidec taking too long to start producing data when the file change time happens.

Does a new file get create in your live tv buffer directory when this happens? Does the file grow beyond zero bytes?

OK I think I have been experiencing two seperate problems.

1. When moving to a new program and a new temp TS file is created. (now seems to be fixed with 1.3.7)

2. Channel just freezes in the middle of a program. Audio continues for a short while but then stops. I have to reboot the PCH to be able to play anything after this has happened. On GBPVR machine the stream is still open and Gbox is still hashing data but Mdapi is not in the system tray. Since upgrading to 1.3.7 the mdapi icon seems to be inconsistanty appearing in the system tray or not but still works regardless. This is unfortunate because I cannot tell whether it is MDAPI that has crashed.

Many thanks to both Martin and Sub for all you have done. I am new to this forum and GBPVR but I can see that you both put a lot of time and effort into this, and of course everyone else who helps out.

Ian

I will upload logs again straight after the event, maybe they will show something.

[tcmy95]

Sub could you please take a look at the attached logs for me.

Many thanks

TCM

[sub]

If you bump this in a week and half, when I'm back in New Zealand, the I'll take a closer look.

[tcmy95]

No probs SUB

[tcmy95]

I noticed another problem which happens now and again, the program will skip back 5 minutes and I have to watch the same thing twice. After looking into this issue I found some users do a quick record and then start watching from the recordings section a minute later. Preliminarily testing appears to be good and the video doesn't skip or freeze as much as watching live TV. Whats different between live tv and a recording apart from the amount of buffering? If it is just the buffer can't I get the same effect using the pre-delay?

Cheers...TCM

[mvallevand]

I don't know the specifics, but I do know is at startup there is a an initial buffer that must be filled before the file will even start playing and then once it starts, there cannot be any zero byte reads in the reads or it will loop. After about 8 seconds things seem to stablize and as long as you can keep sending data to the demux there isn't this problem. I'm guessing that during the decryption process the PCH is hitting no data conditions.

I see (hear?) it most with digital radio which I can't get mono to play live, but in time shifting it works fine. You might be able to increase the delay but you'd have to increase it high to ensure the full 8MB can be read. The code news is the experimental stuff I am working on that doesn't use mono seems to get around this problem for digital radio, and it might work for you.

Martin