TBS: CI/CAM support and other improvements (5 Viewers)

[mm1352000]

Hello again

The issue is this...

It sounds like failure to select (or hold the selection of) the correct DiSEqC port.

Port A is usually the default port for switches, which is probably why you have the most success with port A.

Or, if perhaps anyone knows of something in the patched driver that might induce this behavior.

This patch is not a driver. It communicates with the driver, but it is not the driver itself. The driver is what you download and install from TBS's website to get Windows (or Linux) to recognise the tuner.
There is nothing in the patch that would induce the behaviour. The patch tells the tuner driver to send the requested DiSEqC command; it expects the tuner driver to send the command and the switch to obey the command. As such, if the switch isn't reliable... well it isn't really within our control. About the only thing we could do is try to send the DiSEqC command multiple times. However that slows down tuning/zapping, so no such function has been implemented.

Also, I don't understand why it is that if I happen to shut down TV server while it's recording and then bring it back up, it will restart the recording (if it's still in that time period) but when this problem occurs MediaPortal seems to just give up and not even try to restart the recording.

When recordings stop after 30 seconds it is because the tuner stops delivering the stream not because TV Server actively kills the recording. TV Server doesn't actively check that the tuner is streaming or have any mechanism for attempting to retune if the tuner does stop streaming. In other words, when your recordings are failing TV Server is sitting there thinking it is recording successfully... but actually it is not.

The recording restart that you observe when you "happen to shut down TV Server while it's recording" is a behaviour of the scheduler, which is completely independent to the tuner handling. Every 15 seconds the scheduler checks what recordings should be running and whether they're running or not. It will restart any recordings that stop due to TV Server restart because it can detect the recording is not occurring when it should be. However, the scheduler will not know if the tuner stops streaming.

Regards,
mm

 

[clarkebelt]

Hello again mm1352000, good to hear from you!

Hello again

The issue is this...

It sounds like failure to select (or hold the selection of) the correct DiSEqC port.

Port A is usually the default port for switches, which is probably why you have the most success with port A.

That sounds very logical, and in fact I thought the same thing. But what it doesn't explain is why the DiSEqC would initially tune to the correct port, receive the signal for a minimum of 20 seconds, and THEN (I assume) lose the selection, yet if it gets past that magical two minute mark, the selection is pretty much rock solid and will hold for hours. I don't really expect you to have an answer for that, I am just thinking out loud here - it's rather strange that it would happen that way. You would think that if there were a failure of the DiSEqC switch to hold a connection, it would either happen at the initial tuning attempt, or alternately that if it were an intermittent problem, it would continue to be a problem after the first couple of minutes.

Or, if perhaps anyone knows of something in the patched driver that might induce this behavior.

This patch is not a driver. It communicates with the driver, but it is not the driver itself. The driver is what you download and install from TBS's website to get Windows (or Linux) to recognise the tuner.

I had thought someone had said it was actually a patched driver, but maybe not. Thank you for explaining that.

Just out of curiosity, is it your opinion that the TBS driver itself is in some way buggy? If you can explain what it is doing or not doing that is wrong, I'd be more than happy to contact TBS support and see if they would be willing to do anything to rectify the situation. But since I am not a programmer, I would not have the slightest idea how to describe the issue to them. Maybe this is not the proper thread for that discussion, but I thought I'd ask. Anyway, continuing on...

There is nothing in the patch that would induce the behaviour. The patch tells the tuner driver to send the requested DiSEqC command; it expects the tuner driver to send the command and the switch to obey the command. As such, if the switch isn't reliable... well it isn't really within our control. About the only thing we could do is try to send the DiSEqC command multiple times. However that slows down tuning/zapping, so no such function has been implemented.

For what it's worth, these switches have been very reliable when used with any other tuner or with a standalone receiver - they are Chieta model WSD-2041 which have been highly recommended on some of the satellite forums. I understand that some of the newer 8-port DiSEqC switches are supposed to be even better but MediaPortal doesn't support the 8 port models, so we are pretty much stuck using four port DiSEqC 2.0 switches, and the ones I have are supposed to be among the better ones (in fact we just purchased two more about a month ago because they have been so reliable). They are also among the more expensive models, not that any DiSEqC switch is a wallet buster, but they do cost about 150%-200% of the going price for a generic DiSEqC 2.0 switch.

Regarding tuning/zapping, as I may have mentioned before, I hardly ever watch anything live, so to me personally, being able to reliably record a scheduled program is 1000 times more important to me than speed of tuning/zapping. I could wait an extra second or two for tuning but I can't go back and get a program that the tuner failed to record. So if there is any way you might be able to provide me with a test modification that would try sending the DiSEqC command multiple times, I would be very interested to see if that fixes the problem.

One thing I forgot to mention, and I don't know if this is relevant or not, but I can usually know for sure that this problem will occur if I stop and restart the TV Server. As an example, last weekend we did some work on the system that required taking it offline. Yesterday morning I had it set to record one of the problem channels (the first time I had accessed that channel since the restart), and therefore I set it to record the program before, and sure enough that initial recording failed, but everything after that on that channel recorded with no problem. Today I had it set to record from that same channel again, and again I set it to record the program before the one I really wanted, and this time it did record the earlier program in its entirety. But, I had not stopped the TV server yesterday or today.

I cannot say there is a 100% correlation but I do note that the first attempt at recording from a channel on DiSEqC ports 2, 3, or 4 after a TV server restart is FAR more likely to fail. One reason I even hesitate to mention that is that to me, on one level that makes no sense, but then again nothing about this problem makes much sense to me.

Therefore, I would love to know if sending that DiSEqC command multiple times would actually help. If there is any way you could make that happen I would be willing to give it a try and see if it improves the situation!

Also, I don't understand why it is that if I happen to shut down TV server while it's recording and then bring it back up, it will restart the recording (if it's still in that time period) but when this problem occurs MediaPortal seems to just give up and not even try to restart the recording.

When recordings stop after 30 seconds it is because the tuner stops delivering the stream not because TV Server actively kills the recording. TV Server doesn't actively check that the tuner is streaming or have any mechanism for attempting to retune if the tuner does stop streaming. In other words, when your recordings are failing TV Server is sitting there thinking it is recording successfully... but actually it is not.

The recording restart that you observe when you "happen to shut down TV Server while it's recording" is a behaviour of the scheduler, which is completely independent to the tuner handling. Every 15 seconds the scheduler checks what recordings should be running and whether they're running or not. It will restart any recordings that stop due to TV Server restart because it can detect the recording is not occurring when it should be. However, the scheduler will not know if the tuner stops streaming.

Okay, that actually does correlate with my experience - TV Server does in fact think it is still recording even though the actual stream has apparently stopped. I had not given that a lot of thought until you mentioned it, but it does line up with what I have observed. I wish MediaPortal had some way to detect a stopped stream and decide that it needs to be restarted, but I am guessing this is not a real common issue.

Thanks for the explanation, and as I say, I would be very appreciative if there were any way I could test sending the DiSEqC command multiple times.

 

[mm1352000]

I don't really expect you to have an answer for that, I am just thinking out loud here - it's rather strange that it would happen that way.

Yes, it is strange, and no unfortunately I don't have an answer.
If the failure were closer to the initial tuning I might suspect that we had to tell the driver to send the command at a different time in the tune process, or wait a bit longer after sending the command... or something like that. But 30+ seconds in... I have no explanation for that.

Just out of curiosity, is it your opinion that the TBS driver itself is in some way buggy? If you can explain what it is doing or not doing that is wrong, I'd be more than happy to contact TBS support and see if they would be willing to do anything to rectify the situation. But since I am not a programmer, I would not have the slightest idea how to describe the issue to them. Maybe this is not the proper thread for that discussion, but I thought I'd ask. Anyway, continuing on...

No, I don't think the driver is buggy because it seems to be able to cause the switch to change port successfully. It isn't clear that the driver is the cause of the problem that happens after that, so I don't want to start pointing fingers. Either way it would be definitely be worthwhile to contact TBS support and see what they can do for you.

For what it's worth...

I have a fair amount of head knowledge about DiSEqC, but only limited experience in practice. The one EMP Centauri 9x8 multiswitch I've owned has worked with every tuner I've tried it with... though effectively that is only a 2 port DiSEqC switch with a cascaded 22 kHz switch.

Regarding tuning/zapping...

Updated patch attached. This one sends the command twice every time you tune.

Regards,
mm

 

[clarkebelt]

Updated patch attached. This one sends the command twice every time you tune.

Thank you! I will let you know if it makes any difference after I have used it for a couple of days at least. Much appreciated!

 

[clarkebelt]

Here is my experience after installing that updated patch that mm1352000 graciously provided in post #603.

First of all it made a HUGE improvement in the reliability of tuning after a TV Server restart. What I had found in the past was that any time I stopped and restarted TV Server, the first attempt to tune a channel thereafter would quite often result in failure. This even sometimes occurred on channels I normally have no problem tuning. This patch seems to fix that issue 100%!

As for the other issue, where it starts to record and then after some period of time loses the stream, I will say that this now seems to only be an issue on one channel in particular. I don't know what it is about that channel, but since installing the patch I haven't seen it occur on any other channel. It is still the same issue, if I record say four programs in a row, the first one is likely to fail after anywhere from 30 seconds to two minutes (although the other day I saw it fail after four and a half minutes, no idea why that was different) but the next three will record fine. If the problem stays confined to that channel I can work around it, my only worry is that when the fall TV season arrives and I start trying to record multiple channels simultaneously, I hope the problem does not spread to other channels but instead stays confined to that one channel. Anyway, I have seen that problem occur on that one channel only since the patch was applied, and (so far) not on any other. I have recorded several shows over the weekend, and everything I tried to record has recorded reliably.

I also have not noticed a huge increase in tuning time when live tuning. There was always a short delay when changing channels and as far as I can tell it's not noticeably longer. The tuner has always seemed to have more difficultly locking onto some signals than others (possibly due to weaker transponders?), and that is much more of a factor in tuning speed than any small delay this patch may have introduced, IMHO. As I said earlier I don't normally watch live TV anyway, but if anyone else is having a similar issue I would not let fear of increased tuning time dissuade you from trying the patch (besides, if you save the original DLL, it's easy enough to put it back if necessary).

Thank you mm1352000, this was a major improvement, even if it didn't completely solve the one strange issue!

 

[mm1352000]

@clarkebelt
Thanks for reporting back.
So is everything sorted at this point?

 

[clarkebelt]

@clarkebelt
Thanks for reporting back.
So is everything sorted at this point?

Well, I thought it was up through yesterday. Then I replaced an aging LNB on the Ku dish and after firing that up, it seemed like I had all kinds of problems, specifically on one channel that I haven't had issues with recently. And the problem was really strange - it would work fine for maybe the first five minutes after tuning it in, then get progressively worse, as if the station were drifting off frequency or something. And the strangest part was, this channel is NOT one that is received by the LNB we replaced, although I was having issues with some attempts to use the new LNB also. It finally dawned on me that the thing these had in common was that they both came through the same tuner and DiSEqC switch. So I disabled that tuner temporarily, forcing the use of the other side of the dual LNB's which go through a different DiSEqC switch, and suddenly no problems. So then I tried swapping out the DiSEqC switch on that tuner and re-enabling it and I have been playing that problem channel for over an hour now with no issues.

One theory is that that DiSEqC switch was already failing, but the most recent power down/up cycle was what pushed it over the edge. I do believe that was the oldest DiSEqC switch in the mix, and the one that had been used for quite some time with a standalone receiver. Strangely the switch I replaced it with was a really cheap spare that I had purchased several years ago in case I ever needed a spare switch in a hurry.

I see lots of comments in various forums where people seem to think that DiSEqC switches (at least the ones sold in North America) tend to be really flakey. I know you have to power down the computer before making connections, or you can fry the DiSEqC, but even with that precaution they have a tendency to fail for no particular reason. The Chieta switches we are using (including the one that failed) are supposed to be the best of the reasonably-priced switches; they cost about double what the cheapest models cost but I have read you can also buy ones costing a lot more that are supposed to be even more reliable. Personally I wonder whether the best approach would be to buy a "good" switch and hope it lasts (I imagine even a "good" one could be taken out by nearby lightning), or just keep buying inexpensive ones and replace them as they fail.

Anyway I am not quite prepared to say that absolutely everything is sorted (still haven't been able to figure out how to tune Ku without entering equivalent pseudo-C band frequencies, but then again I haven't spent any more time on that since I got it working by using fakeout C-band frequencies), but for the moment it seems that most of the issues are being dealt with, one by one. I just wish there weren't quite so many times where it feels like I take one step forward and two steps back. But I have made considerable progress since first starting this, in large part thanks to your help.

I wonder is there is such a thing as a reliable 4-port DiSEqC 2.0 switch that doesn't cost an arm and a leg? Probably should ask that in a different thread, since I suppose it's off-topic for this one.

 

[dolofsson]

Can anyone verify if 1.6 patch works for MP ver 1.9? (Using TBS 5881, fresh install mp 1.9 and experience problems. New user though so I haven't used tbs 5881 or MP before.)

 

[mm1352000]

Can anyone verify if 1.6 patch works for MP ver 1.9? (Using TBS 5881, fresh install mp 1.9 and experience problems. New user though so I haven't used tbs 5881 or MP before.)

Hello and welcome!
Yes, it should do. Post your log files and describe the problem(s) if you want help:
http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/16_Support/3_Forums/2_Log_Files

 

[johanj]

I can confirm that the 1.6 patch works fine also with MP 1.9 and TBS 5881