- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
Hi all
I have a couple of questions and a potential bug report for the developers. Let me start by giving some brief background...
I have a 90cm [offset] satellite dish with 2 twin output LNBs (one centre position, the second offset by 8 degrees to the left) which are controlled by a 9x8 multiswitch (which provides the feeds for my PC TV tuner cards). Signal strength/quality on the offset LNB is never going to be ideal, however it is adequate for all of the transponders except for 2. DVBViewer 4.2.1.0 is able to pick up the stronger of those 2 transponders (~85% quality) relatively consistently as long as the weather is reasonable. It can also pick up the weakest transponder (~70% quality) with some pixelation when the weather is good. Unfortunately I have found that MediaPortal (version 1.1.0, 1.1.1, SVN) is not able to match DVBViewer. Using the same tuner, MediaPortal can only occasionally pick up the '85% transponder'. I have only known MediaPortal to pick up the '70% transponder' on 2 occasions in the last 2-3 months.
When comparing MediaPortal and DVBViewer I use:
- the same tuner
- the same cable
- try to tune at approximately same time (within 10 seconds, and obviously not at the same time)
This situation is quite frustrating for me because I really enjoy watching some of the channels on the weak transponders. MediaPortal is my software of choice for TV
D) so it is not ideal to have to use DVBViewer for the channels on the two weak transponders!
I have tried a couple of things to improve my chances of receiving the weak transponders in MediaPortal:
- increased the scan timeouts (tune = 10 seconds)
- increased the TV Server priority to real time
- tried to mimic the settings in DVBViewer (such as stop graph rather than pause)
Nothing seems to have made any difference...
The relevant section of my log is below. As you can see, the signal is simply not being locked because it is bad or weak.
Now I come to the two questions for the developers:
1. In the log above, my tune timeout was 20 seconds and my TV Server priority was real time. As you can see, the server definitely waits 10 seconds for lock, *however* after the first 5 attempts (~800ms) the TV Server will sleep for the remaining ~19 seconds!!! Surely this shouldn't happen. As a programmer I know that thread scheduling is not something you can control, however this behaviour is very consistent for me. 5 attempts, and then sleep for the remaining time, no matter what priority the TV Server has or how long or short the timeout is. The only trouble is that the minute I try and insert any extra debugging to see where the time is being spent, the thread will behave like I expect it should (more regular scanning). Looking at the code (TVLibrary.Implementations.DVB.Graphs.TvCardDvbBase.LockedInOnSignal()) I can't see any reason why this should happen *but it does*. Perhaps this behaviour is related to characteristics of the CLR scheduler?
2. I notice there is a put_SampleTime() function in the IBDA_SignalStatistics class. I wondered whether there was a reason that this function is not used when checking the signal for lock?
Any comments would be welcome!
[Edit: note that I am using Windows XP SP3]
I have a couple of questions and a potential bug report for the developers. Let me start by giving some brief background...
I have a 90cm [offset] satellite dish with 2 twin output LNBs (one centre position, the second offset by 8 degrees to the left) which are controlled by a 9x8 multiswitch (which provides the feeds for my PC TV tuner cards). Signal strength/quality on the offset LNB is never going to be ideal, however it is adequate for all of the transponders except for 2. DVBViewer 4.2.1.0 is able to pick up the stronger of those 2 transponders (~85% quality) relatively consistently as long as the weather is reasonable. It can also pick up the weakest transponder (~70% quality) with some pixelation when the weather is good. Unfortunately I have found that MediaPortal (version 1.1.0, 1.1.1, SVN) is not able to match DVBViewer. Using the same tuner, MediaPortal can only occasionally pick up the '85% transponder'. I have only known MediaPortal to pick up the '70% transponder' on 2 occasions in the last 2-3 months.
When comparing MediaPortal and DVBViewer I use:
- the same tuner
- the same cable
- try to tune at approximately same time (within 10 seconds, and obviously not at the same time)
This situation is quite frustrating for me because I really enjoy watching some of the channels on the weak transponders. MediaPortal is my software of choice for TV
D) so it is not ideal to have to use DVBViewer for the channels on the two weak transponders!I have tried a couple of things to improve my chances of receiving the weak transponders in MediaPortal:
- increased the scan timeouts (tune = 10 seconds)
- increased the TV Server priority to real time
- tried to mimic the settings in DVBViewer (such as stop graph rather than pause)
Nothing seems to have made any difference...
The relevant section of my log is below. As you can see, the signal is simply not being locked because it is bad or weak.
Code:
2010-10-17 03:29:19.843750 [(6)]: Blackgold: CommitChanges() Succeeded
2010-10-17 03:29:19.953125 [(6)]: dvb: LockedInOnSignal waiting 20ms
2010-10-17 03:29:19.984375 [(6)]: dvb: LockedInOnSignal waiting 20ms
2010-10-17 03:29:20.015625 [(6)]: dvb: LockedInOnSignal waiting 20ms
2010-10-17 03:29:20.046875 [(6)]: dvb: LockedInOnSignal waiting 20ms
2010-10-17 03:29:20.078125 [(6)]: dvb: LockedInOnSignal waiting 20ms
2010-10-17 03:29:39.984375 [(6)]: dvb: LockedInOnSignal could not lock onto channel - no signal or bad signal
2010-10-17 03:29:39.984375 [(6)]: tvcard:FreeSubChannel: subchannels count 1 subch#0 keep graph=FalseNow I come to the two questions for the developers:
1. In the log above, my tune timeout was 20 seconds and my TV Server priority was real time. As you can see, the server definitely waits 10 seconds for lock, *however* after the first 5 attempts (~800ms) the TV Server will sleep for the remaining ~19 seconds!!! Surely this shouldn't happen. As a programmer I know that thread scheduling is not something you can control, however this behaviour is very consistent for me. 5 attempts, and then sleep for the remaining time, no matter what priority the TV Server has or how long or short the timeout is. The only trouble is that the minute I try and insert any extra debugging to see where the time is being spent, the thread will behave like I expect it should (more regular scanning). Looking at the code (TVLibrary.Implementations.DVB.Graphs.TvCardDvbBase.LockedInOnSignal()) I can't see any reason why this should happen *but it does*. Perhaps this behaviour is related to characteristics of the CLR scheduler?
2. I notice there is a put_SampleTime() function in the IBDA_SignalStatistics class. I wondered whether there was a reason that this function is not used when checking the signal for lock?
Any comments would be welcome!
[Edit: note that I am using Windows XP SP3]
