CableCARD tuner support for MediaPortal 1 (5 Viewers)

[Sigpi007]

UPDATE: This just went from weird to bad. Whole TV server locked up mid-day while I was at work. Had to dial in via TeamViewer to see what was going on. I found 6 or 7 TS files were maxed out at 1gig each in the Timeshifting folder. Same files names as were referenced in the logs I sent. I couldn't even close the TV Service gracefully as it perpetually said "stopping" in services.msc when I tried to "Stop Service" in the manual control section of the TV config. Had to reboot computer. Tuners on Ceton were locked when computer came back up. Had to have my mom (babysitting my son while i'm at work) unplug and replug in the Ceton Eth tuner. Everything worked well after that.

 

[mm1352000]

Is there a way to mark them all at once?

No, not through TV Server configuration. Unfortunately there is no way to mark the channels correctly - the scrambled flag is not available. About the best you can do is:
1. Export the channel list in the import/export section.
2. Open the export file in any text editor (notepad, wordpad etc.).
3. Edit the value for "FreeToAir", change from "False" to "True" for the channels you know are free.
4. Save changes.
5. Delete the channels in TV Server configuration.
6. Reimport the export file.

 

[breese]

Thanks.. Done
Is there anything else I can help you with?

 

[mm1352000]

Hello again Sigpi007

Been testing the new patch you made on MP1.5PR, and to some extent it has helped the channel changing lag. But, overall MP seems a little "sluggish" like in the menu and such.

It is really hard to give you a helpful response to this issue for several reasons. First, I don't have the MP log files. Second and more importantly, "sluggish" and "laggy" are really subjective.
Possibly the only suggestion I can make is in terms of the channel change lag. If you're keying in numbers on a remote and seeing MP is taking a while to change channel, look here:
http://wiki.team-mediaportal.com/1_...al_Configuration/13_GUI/6_On-Screen_Display_*

Change the zap timeout down from 5 to 1 (0 won't work).

And then this morning, the TVservice was stopped for no reason.

You're gonna have to help me out here. Being based in New Zealand and not even knowing whether you're on the East coast or West coast... working out the time zones to know what date you're talking about is tough. I think you mentioned the date and time below?

1.) MPIPTVSource - buffer free space too small??

Without having access to your system log files I can only guess at what happened here, but I think your network connection dropped out.

Had to restart TVServer at 7:06 AM on 08-26. Looks like something stopped the service around 2AM that morning.

Yeah, right around the time when SchedulesDirect was updating your database.

[2013-08-26 02:55:11,389] [Log ] [SchedulesDirect EPG Client] [INFO ] - Tvservice stopped due to an unhandled app domain exception Error: DatabaseUnavailableUnclassified

2.) TsWriter-2013-08-26.log => lots of entries for ---BUG-3782 fix v2---

Absolutely normal. It just indicates the version of TsWriter, though I usually forget to update it when I make changes. Please ignore.

3.) TsWriter-2103-08-25.log => from 14:21:04 through 16:28:00... lots of trouble writing to a ts file.

How much free space does the d: drive have?
Is it possible you paused TV and forgot about it?
I find it interesting that 16:28 is right around the time when the buffer free space too small messages are seen in the IPTV log.

4.) Lots of errors in TVService1.log and TVService-Error1.log

You're right - there are a lot of errors. This post is already getting quite long but I'll make a few comments here about specific messages:

DRI CC: failed to handle state variable change
System.ArgumentOutOfRangeException: Length cannot be less than zero.
Parameter name: length
at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
at TvLibrary.Implementations.Dri.TunerDri.HandleMmiMessage(Byte[] message)
at TvLibrary.Implementations.Dri.TunerDri.OnStateVariableChanged(CpStateVariable stateVariable, Object newValue)

This one is in relation to the tuner trying to send you a message from the CableCARD:

<HTML><BODY><CENTER><BR><BR>Cisco CableCARD(tm)<BR>--------------------------------<BR>CableCARD firmware upgrade<BR>could not proceed further,<BR>Host not responding.<BR>Please contact the retailer.<BR></BODY></HTML>

Messages from your Cisco CableCARD are a different format compared to the Motorola cards that I had access to in testing. I'll take a look at fixing this issue this evening.

DRI: failed to subscribe to state variable events for service

Every half hour or so TV Server is meant to check in with the tuner to confirm it should continue to receive updates from the tuner. This message indicates that the something is going wrong with that in your environment. It may be related to the fact that you're preloading all 6 of your tuners.

mm

 

[mm1352000]

I found 6 or 7 TS files were maxed out at 1gig each in the Timeshifting folder. Same files names as were referenced in the logs I sent.

Timeshift file names are standard. The fact that they're present indicates somebody was using the tuner at the time.

I couldn't even close the TV Service gracefully as it perpetually said "stopping" in services.msc when I tried to "Stop Service" in the manual control section of the TV config. Had to reboot computer.

Need log files to diagnose.

Tuners on Ceton were locked when computer came back up.

Probably because the tuners were in use and the TV service wasn't cleanly shut down.

 

[Sigpi007]

I appreciate the quick response mm. Kicking myself for omitting the MP client logs! (see attached)

My D: drive has 1.5TB free... and is dedicated only to Timeshifting and Recordings... so I'm guessing that I should be square with having enough freespace.

Based on your linkage of the symptoms to the SD plugin, I'm wondering if this issue is similar to the one discussed in "[WiP] - TSWriter deadlock potential fix" in the forums??

 

[twemperor]

@mm1352000, I'm still having tuner lockup issues. I've attached logs. Scanning appears to work fine, but after a 'successful' recording, I can't use tuner #1 anymore (recordings for other tuners continue). Oddly, the other tuners don't seem to lock up as much (I don't normally have more than 2 or 3 at once), and timeshifting doesn't seem to cause this.

I'm currently running 1.5PR, and I've applied the patch from here: https://forum.team-mediaportal.com/...for-mediaportal-1.112585/page-50#post-1022232

I didn't think it was related (since I have a Ceton, and not an HDHR), but also didn't think it would hurt to adjust the RTSP teardown request timeout, from this post: https://forum.team-mediaportal.com/...for-mediaportal-1.112585/page-46#post-1018349

I was starting to wonder if I had a hardware problem with the Ceton, and Ceton tech support recommended getting a new CableCard (which I did). They suggested the following:

We have gone over the diagnostic information you provided and it appears that the infiniTV is timing out waiting for the CCI information. The content provider and the content distributor determine the CCI value for each program. The Cable Authentication System delivers the CCI for each program securely to the CableCARD. The CableCARD passes CCI to the infiniTV through a secure authentication protocol, run once for each copy protected program being decrypted. The infiniTV uses the CCI to control copy creation, copy control encoding and to set copy control parameters for a particular program. CCI is time sensitive and if the infiniTV does not receive the CCI within a specific timeframe it will timeout causing an error message to appear. We believe that the problem is either the CableCARD itself is malfunctioning and not passing the CCI to the infiniTV within the allotted time or the cable provider has mis-provisioned your account and the CCI is not being sent at all. We would suggest first swapping out the CableCARD to see if that is where the issue is. If the problem continues to happen after swapping the CableCARD then we will need to engage the cable provider to verify your account is setup and authorized properly.

Do you have any other thoughts? The logs show exceptions in the DRI interface, so I've switched to the older PBDA interface since that seemed more stable for me before (and College Football is about to start, so failed recordings is a non-starter).

 

[mm1352000]

I appreciate the quick response mm. Kicking myself for omitting the MP client logs! (see attached)

No problem.
I think if you disable the HTPCInfo plugin you'll have MP running a lot more smoothly.

My D: drive has 1.5TB free... and is dedicated only to Timeshifting and Recordings... so I'm guessing that I should be square with having enough freespace.

Yeah, that should be plenty. Hmmm... I'll have to think further on that one.

Based on your linkage of the symptoms to the SD plugin, I'm wondering if this issue is similar to the one discussed in "[WiP] - TSWriter deadlock potential fix" in the forums??

At this stage I think that issue is totally unrelated. It only seems to manifest when using the DVB EPG grabber:
http://wiki.team-mediaportal.com/1_...figuration/TV-Server_Configuration/05_DVB_EPG

 

[mm1352000]

@twemperor, @Sigpi007

I'm sorry that both of you are still having trouble. You both seem to have multiple issues contributing to what you're observing, and that makes it tougher for me to figure out and solve the most important problems.

For example, Sigpi007 I think the HTPCInfo plugin may have been quite a big factor in the laggy/sluggish MP behaviour that you noted, but I think your wireless network may also be contributing to unreliability in communication with the tuner which could also introduce delays at times. Then there was the [minor] CableCARD firmware upgrade message all through the log files making it difficult to spot the key important errors.

twemperor, I'll expand on what I see in your log files below but I just have the feeling something is not right with your network. Network seems to be a consistent factor in all of the things you've reported.

Anyhow, I wanted to say thanks for your patience and your willingness to work with me here - it is really appreciated.

I'm still having tuner lockup issues. I've attached logs. Scanning appears to work fine, but after a 'successful' recording, I can't use tuner #1 anymore (recordings for other tuners continue). Oddly, the other tuners don't seem to lock up as much (I don't normally have more than 2 or 3 at once), and timeshifting doesn't seem to cause this.

First thing to say: I see one problem there which is related to the issue that the patch was meant to address. It explains the reason for the failure to timeshift with tuner #1. I'll provide a new patch this evening as soon as humanly possible.

Second, I see a lot of continuity errors in your TsWriter and IPTV source log files. At first glance there appears to be a correlation between these errors and the timing for attempting to stream (either timeshift or record) two channels at once. That along with the consistently slower tuner detection and persistent but random tuner communication issues... that is why I suspect issues with your network or network configuration.
...but since you're using Argus and shares for timeshift/record... there are many possible contributing factors to work through.

I'm currently running 1.5PR, and I've applied the patch from here: https://forum.team-mediaportal.com/...for-mediaportal-1.112585/page-50#post-1022232

Yep, that is good.
As above, I'll provide an update on this in a few hours.

I didn't think it was related (since I have a Ceton, and not an HDHR), but also didn't think it would hurt to adjust the RTSP teardown request timeout, from this post: https://forum.team-mediaportal.com/...for-mediaportal-1.112585/page-46#post-1018349

Yeah, I agree that it probably isn't related but it definitely doesn't hurt to bump that setting up a few notches.

I was starting to wonder if I had a hardware problem with the Ceton, and Ceton tech support recommended getting a new CableCard (which I did). They suggested the following...

Interesting. The stuff they're talking about is outside my control. It might explain some of the earlier PMT timeout issues I was seeing, but there are currently other things which appear to be happening more frequently.

Do you have any other thoughts? The logs show exceptions in the DRI interface, so I've switched to the older PBDA interface since that seemed more stable for me before (and College Football is about to start, so failed recordings is a non-starter).

No more than what I've said above really. From my perspective I'll continue to provide patches where I see issues that need to be addressed, and I'm hoping you'll continue to report anything you notice. The expectation would be that this process of gradual improvement would eventually allow us to unravel and fix the issues that are contributing to the instability that you're experiencing.


So summary:
1. Big thanks for your ongoing feedback!
2. Expect a new patch in the next 24 hours.

mm

 

[mm1352000]

Hello again everyone

So, attached is a patch to fix some of the issues that have been reported for MP 1.5 PR. This patch contains:

1. The original fix that I made for Sigpi007's slow tuning.
2. The changes that breese has been testing for clear QAM tuners.
3. The promised tweak to the slow tuning (ie. twemperor's locked tuner fix).
4. A fix for the Cisco CableCARD message parsing as promissed to Sigpi007.

This patch is designed to be installed over top of MP 1.5 PR. I don't intend to provide backports to MP 1.4 or MP 1.3 at this stage (if at all).

I'd consider some of the fixes in here to be really worth having if you want a reliable setup. I want them to get into MP 1.5 [final], but that will require plenty of testing from the community to confirm (a) that the fixes work and (b) that they don't cause issues for working setups. So everybody running MP 1.5 PR is welcome to test.

Note:

• I've removed patches posted in the last few pages to avoid confusion about patch versions - the one attached here is the one to use
• [for team members reading this] I consider the patch to be work in progress, meaning further fixes may be required depending on feedback

mm