home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
TBS: CI/CAM support and other improvements
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="clarkebelt" data-source="post: 1094207" data-attributes="member: 148422"><p>Hello again mm1352000, good to hear from you!</p><p></p><p></p><p></p><p>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.</p><p></p><p></p><p></p><p>I had thought someone had said it was actually a patched driver, but maybe not. Thank you for explaining that.</p><p></p><p>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...</p><p></p><p></p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>I cannot say there is a 100% correlation but I do note that the <strong>first</strong> 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.</p><p></p><p>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!</p><p></p><p></p><p></p><p>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.</p><p></p><p>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.</p></blockquote><p></p>
[QUOTE="clarkebelt, post: 1094207, member: 148422"] Hello again mm1352000, good to hear from you! 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. 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... 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 [B]first[/B] 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! 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. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
TBS: CI/CAM support and other improvements
Contact us
RSS
Top
Bottom