Calling all MP New Zealanders (Both of you!!) (2 Viewers)

[mm1352000]

Unfortunately the holiday was just a couple of weeks ago and it was running 1.6.0.

Switching the EPG idle refresh timer back to 4 or fewer hours and trying to make it crash is not something I'm wanting to do as it's heavily used by the family.

Okay, well that is unfortunate. I do understand. It is just another [potential] problem that will never be fixed.

May I ask how the "EPG grabbing while timeshifting/recording" works. I've never used it as it never made sense to me and couldn't find any information.

The timeshifting EPG grabber is no different to the idle EPG grabber in terms of what it does. It only differs in when it will grab the data.
The idle EPG grabber starts a timeshift session to grab EPG when all your tuners are idle.
The timeshifting EPG grabber uses your timeshift and record sessions to grab EPG. Note that the channel and tuner must both be enabled for EPG grabbing, otherwise the grabber won't grab.
Make sense?

Is this able to get all DVB-S channels EPG while recording one channel using the same tuner?

Yes... if the EPG data for all your channels is available from the transponder that carries the channel that you're recording. Same abilities/constraints as the idle EPG grabber apply.

 

[rlevis]

Okay, well that is unfortunate. I do understand. It is just another [potential] problem that will never be fixed

Well, it just so happens you are in luck! That issue occurred today. Although it is much less common with EPG refresh at 12 hours, it still happens on rare occasions.

I didn't notice the issue until I loaded TV Server config to check what you were referring to here...

Note that the channel and tuner must both be enabled for EPG grabbing, otherwise the grabber won't grab.

I selected the 2nd DVB-S2 tuner and it showed me the scanning options. I clicked on the 1st DVB-S2 tuner and TV server config hung. Had to end task. I tried it a couple of times with same result. DVB-T tuners would show their scanning options fine.

I then noticed TV1 news wasn't recording. No channels can be viewed/recorded on any DVB-T or S tuners.

In Windows Services, selected Restart, and TV Service shows Stopping, but never stops as I described. Had to reboot the PC.

Attached logs.

 

[mm1352000]

Well, it just so happens you are in luck! That issue occurred today. Although it is much less common with EPG refresh at 12 hours, it still happens on rare occasions.

Excellent.
So let's see...
Looks like the problem starts with a failed recording at 10:43 AM on the 13th. TV Server fails to stop the tuner:

[2014-02-13 10:43:17,556] [Log ] [scheduler thread] [INFO ] - card: WaitForFile - no audio was found after 15.0018581 seconds
[2014-02-13 10:43:17,559] [Log ] [scheduler thread] [INFO ] - card: Recording failed! 18 D:\Videos\Recorded TV\Big Time Rush - Nickelodeon - 2014-02-13.ts
[2014-02-13 10:43:17,560] [Log ] [scheduler thread] [INFO ] - card: StopRecording card=18, user=scheduler1237
[2014-02-13 10:43:17,561] [Log ] [scheduler thread] [INFO ] - basesubchannel.StopRecording 0
[2014-02-13 10:43:17,561] [Log ] [scheduler thread] [INFO ] - tvdvbchannel.OnStopRecording subch=0, subch index=0
[2014-02-13 10:43:17,563] [Log ] [scheduler thread] [INFO ] - tvdvbchannel.OnStopRecording subch:0-0 tswriter StopRecording...
[2014-02-13 10:43:17,564] [Log ] [scheduler thread] [INFO ] - FreeSubChannel MD: freeing sub channel : 0
[2014-02-13 10:43:17,565] [Log ] [scheduler thread] [INFO ] - mdplug: FreeChannel Nickelodeon
[2014-02-13 10:43:17,566] [Log ] [scheduler thread] [INFO ] - mdplug: usage counter for channel 'Nickelodeon' is zero
[2014-02-13 10:43:17,567] [Log ] [scheduler thread] [INFO ] - tvcard:FreeSubChannel: subchannels count 1 subch#0
[2014-02-13 10:43:17,568] [Log ] [scheduler thread] [INFO ] - DVB subch:0 Decompose()
[2014-02-13 10:43:17,569] [Log ] [scheduler thread] [INFO ] - FreeSubChannel CA: freeing sub channel : 0
[2014-02-13 10:43:17,569] [Log ] [scheduler thread] [INFO ] - tvcard:FreeSubChannel : no subchannels present, pausing graph
[2014-02-13 10:43:17,569] [Log ] [scheduler thread] [INFO ] - dvbtopGraph called
[2014-02-13 10:43:17,570] [Log ] [scheduler thread] [INFO ] - tvcard:FreeAllSubChannels
[2014-02-13 10:43:17,570] [Log ] [scheduler thread] [INFO ] - mdplug: FreeAllChannels
[2014-02-13 10:43:17,571] [Log ] [scheduler thread] [INFO ] - dvbtopGraph

[2014-02-13 10:43:17,571] [5c4b560] [2894] - CMpTsFilter:ause()
[2014-02-13 10:43:17,571] [5c4b560] [2894] - Pause filter...
[2014-02-13 10:43:17,571] [5c4b560] [2894] - HRESULT = 0x0
[2014-02-13 10:43:17,601] [5c4b560] [2894] - CMpTsFilter:top()
[2014-02-13 10:43:17,601] [5c4b560] [2894] - Stop streaming...
[2014-02-13 10:43:17,601] [5c4b560] [2894] - Stop filter...
[2014-02-13 10:43:17,601] [5c4b560] [2894] - HRESULT = 0x0

What this shows is that one of the filters in the tuner graph failed to stop. This causes a deadlock very similar to the EPG grabber issue. If everything were working correctly we should see a "[scheduler thread] [INFO ] - debug: IMediaControl stopped! hr = 0x0 " entry after that "dvbtopGraph".

The filter that fails to stop is most likely to be one of the tuner or plugin filters. I'm afraid this is where I have to stop since this could be caused by the plugin (hopefully you know about our policy). If you could reproduce the problem without the plugin enabled then that would probably confirm the tuner filter is not stopping... however I take it that would be difficult given the required downtime on Sky channels for the rest of the family? I would suggest that it would be worth proactively pursuing a solution for this problem. WAF/FAF will quickly drop if TV Server can't timeshift or record reliably... and scheduled service restarts won't help with this. Once a deadlock hits, only a full system reboot will unlock the service.

I note that you appear to be pulling in EPG with the XMLTV plugin so I can't see how changing the refresh time for the DVB EPG grabber would make an iota of difference to this problem.

Note that the channel and tuner must both be enabled for EPG grabbing, otherwise the grabber won't grab.

I selected the 2nd DVB-S2 tuner and it showed me the scanning options. I clicked on the 1st DVB-S2 tuner and TV server config hung. Had to end task. I tried it a couple of times with same result. DVB-T tuners would show their scanning options fine.

I have the impression you're looking in the wrong place. I think you're referring to:
http://wiki.team-mediaportal.com/1_...rver_Configuration/02_TV_Servers/3_Scan_DVB-S

I was referring to "allow this card to be used for EPG grabbing":
http://wiki.team-mediaportal.com/1_...nfiguration/02_TV_Servers#Edit_Tuner_Settings

TV Server config hung because of this:
[collapse]
[2014-02-13 18:46:12,849] [Log ] [SetupTv ] [ERROR] - Exception ystem.Net.Sockets.SocketException (0x80004005): An established connection was aborted by the software in your host machine
Server stack trace:
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Runtime.Remoting.Channels.SocketStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at System.Runtime.Remoting.Channels.SocketHandler.ReadFromSocket(Byte[] buffer, Int32 offset, Int32 count)
at System.Runtime.Remoting.Channels.SocketHandler.Read(Byte[] buffer, Int32 offset, Int32 count)
at System.Runtime.Remoting.Channels.SocketHandler.ReadAndMatchFourBytes(Byte[] buffer)
at System.Runtime.Remoting.Channels.Tcp.TcpSocketHandler.ReadAndMatchPreamble()
at System.Runtime.Remoting.Channels.Tcp.TcpSocketHandler.ReadVersionAndOperation(UInt16& operation)
at System.Runtime.Remoting.Channels.Tcp.TcpClientSocketHandler.ReadHeaders()
at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)
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 TvControl.IController.SignalLevel(Int32 cardId)
at SetupTv.Sections.CardDvbS.UpdateStatus()
at SetupTv.Sections.CardDvbS.OnSectionActivated()
at SetupTv.SetupTvSettingsForm.ActivateSection(SectionSettings section)[/collapse]

I suspect this may be related to the deadlock.

I then noticed TV1 news wasn't recording. No channels can be viewed/recorded on any DVB-T or S tuners.

That's due to the deadlock.

In Windows Services, selected Restart, and TV Service shows Stopping, but never stops as I described. Had to reboot the PC.

Also due to the deadlock.

mm

 

[rlevis]

I note that you appear to be pulling in EPG with the XMLTV plugin so I can't see how changing the refresh time for the DVB EPG grabber would make an iota of difference to this problem.

XMLTV is used for the freeview DVB-T channels only, plus a small number of DVB-S channels which don't work in the DVB EPG system.

The deadlock does seem to be a new thing since implementing Sky viewing so it is likely related to the tuner MDPlugin. I see Benoire is back and was using the same configuration as mine, along with dozens of others. if you are reading this, did you have similar problems?

 

[Benoire]

I note that you appear to be pulling in EPG with the XMLTV plugin so I can't see how changing the refresh time for the DVB EPG grabber would make an iota of difference to this problem.

XMLTV is used for the freeview DVB-T channels only, plus a small number of DVB-S channels which don't work in the DVB EPG system.

The deadlock does seem to be a new thing since implementing Sky viewing so it is likely related to the tuner MDPlugin. I see Benoire is back and was using the same configuration as mine, along with dozens of others. if you are reading this, did you have similar problems?

G'day fella,

I've had no problems currently with DJblu's modified v1.6 since installing it earlier this week. About to use the Sky Card (once the missus has finished watching the Aussie bachelor, shudder) so will see but I've had lots of FTA on record/playback with the 'Plugin that shall not be named' installed and they've all completed fine (unlike the bloody ESXi install which failed, now using xenserver 6.2). To be honest, I only suffered the lock on a much earlier version way back around 1.3 I think which is why I shifted to Argus briefly.

 

[rlevis]

Looks like the "lock" is still there and you may come across it eventually once you are watching/recording sky channels.

It's not something that has occurred a lot, perhaps 6 times over the last 4 months, and various family members are recording lots of programs.

Although it doesn't seem related to EPG, I've changed TV Server to only read EPG while recording/timeshifting rather than idle and I'll see if that makes any difference. I'm wondering if it occurs when EPG has been gathering just before a recording starts,so stop the idle EPG and see.

Otherwise I may be forced to try the DJblu mods to see if that fixes it, or perhaps use XMLTV for all EPG, although it's not ideal as program descriptions are truncated after so many characters when importing with XMLTV. I've asked whoever is responsible for that plugin to fix it in the past but never had any response on the forums.

 

[mm1352000]

It's not something that has occurred a lot, perhaps 6 times over the last 4 months, and various family members are recording lots of programs.

That is helpful info - thanks.

Although it doesn't seem related to EPG, I've changed TV Server to only read EPG while recording/timeshifting rather than idle and I'll see if that makes any difference. I'm wondering if it occurs when EPG has been gathering just before a recording starts,so stop the idle EPG and see.

In your previous log files there was no EPG grabbing between TV Server start and the lock, which is why I said that it looked like you were only using the XMLTV plugin.

...although it's not ideal as program descriptions are truncated after so many characters when importing with XMLTV. I've asked whoever is responsible for that plugin to fix it in the past but never had any response on the forums.

It is a built in plugin => team is responsible. Report a bug please if you want action taken:
https://forum.team-mediaportal.com/forums/bugreports.74/

Before you report the bug, please double check that the XMLTV file actually contains the full text that you're expecting. I think it would be highly unusual for the XMLTV plugin to truncate text. Far more likely that the XMLTV file doesn't contain the full text (due to limitations in the size of the broadcast description field - note, depends on collection type [OpenTV or EIT]) or the database column doesn't have the required capacity.

 

[Benoire]

@mm1352000

I've been playing with RTSP and UNC playback options and have a few questions if I may? I think you know my setup, fully virtualised Windows Server 2012 R2 with Xenserver 6.2 as the host Dom0 utilising PCI passthrough for the two TBS 6981s. Anyway, TVServer (DJBlu mods) work fine, record, playback etc. but recorded TV is best via RTSP (i.e. playback is almost instant) but live tv (timeshift) is better via UNC; times are around 6s tune for HD and 4s SD with Sky via windows domain. If I try and flip Live TV, RTSP method takes absolutely ages to connect... Ignoring the extra time the cam adds to the process in TV server AND the domain (adds around 1s to the time, so 3s extra due to process), is there any particular reason why RTSP Live TV takes so much longer to connect (I've seen 15s or so for an HD channel). If you want logs just ask, but it was more of a curiosity around connections.

Cheers,

Chris

 

[rlevis]

Just adding my 0.2 cents. I switched to UNC mode about a year ago in my separate client/server configuration and find UNC faster for both live TV and recorded TV, particularly seeking. However, if the client PC has been asleep, when it wakes up, it can take around 10 seconds to start a live channel. After that, all other live channels start very quickly.

I'm using the server IP address rather than PC name as I've had some issues with the server PC not being accessible via the PC name for some strange reason. Both are Win7 Ultimate SP1.

 

[Benoire]

UNC should be faster, simply as the client has access to the raw TS file, I just find it interesting that RTSP playback for recorded TV is a lot faster than a live TV tune... I would have thought bar the initial tune/rtsp setup it should stream quite quickly.

I will obviously add that the Windows Domain will add time to the connection via SMB and that the soft cam approach also adds time, this is fine and I accept that I was just curious really.

Because my network is built around AD for other reasons, it is an unfortunate requirement for my tv setup too.