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
Support
Electronic Program Guide
Scheduled recordings not always highlighted in guide
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="CyberSimian" data-source="post: 1120885" data-attributes="member: 141969"><p>In my previous post I described the problem that I noticed for the first time last week, namely <em>vanishing EPG highlighting</em>. In this post I want to describe a workaround for the problem that I noticed soon after starting to use MP several months ago, namely <em>missing EPG highlighting</em>. This workaround may (or may not) also fix the problem of vanishing EPG highlighting. First let us have a recap of where we are with this problem:</p><p></p><p>(1) This thread is but the most recent of several earlier threads concerning this problem (see earlier post).</p><p></p><p>(2) Someone in an earlier thread (not me!) wondered if the problem was caused by the SQL query timing out.</p><p></p><p>(3) [USER=57999]@RobNorthcott[/USER] commented that he was experiencing this problem on an HTPC that he considered "weak", and I commented that my HTPC had a slow operating-system disk (the one used for the SQL databases).</p><p></p><p>(4) [USER=82144]@mm1352000[/USER] examined Rob's logs and observed that his system was grabbing the EPG at the time of the problem.</p><p></p><p>(5) The next time this problem occurred on my system, I examined the TV Server logs and also found that EPG grabbing was occurring at that time.</p><p></p><p>So the indications seem to be that the problem occurs when the system is grabbing the broadcast EPG on a "weak" HTPC.</p><p></p><p>Some weeks ago I modified my EPG-grabbing settings in order to cure an unrelated problem (with help from mm <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" />); see this thread:</p><p></p><p><a href="https://forum.team-mediaportal.com/threads/recording-failed-to-start.128150/" target="_blank">https://forum.team-mediaportal.com/threads/recording-failed-to-start.128150/</a></p><p></p><p>I ended up with: grab when idle, grab when timeshifting/recording, grab from one 24-hour channel per MUX. However, we did not discuss the <strong>Grab EPG only for channels on same transponder</strong> setting, and it is enabling this setting that seems to avoid the problem of missing EPG highlighting. So what is going on here?</p><p></p><p>The reason that I believe this works for the UK EPG is the way in which the data is transmitted. Instead of broadcasting the entire EPG for channel 1, followed by the entire EPG for channel 2, and so on, the data for different channels is <em>interleaved</em>. Consequently, if the data for channels in other MUXes is ignored, it significantly reduces the rate at which SQL updates are generated, and hence reduces the load on a "weak" system.</p><p></p><p>If (say) it takes 5 minutes to transmit once the entire EPG for the 6 SD MUXes in the UK, grabbing the EPG for all MUXes would capture the entire EPG in just 5 minutes, but produce a very high SQL transaction rate. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite3" alt=":(" title="Frown :(" loading="lazy" data-shortname=":(" /></p><p></p><p>In contrast, ignoring the EPG for channels in other MUXes means that the EPG Grabber must tune <em>in turn</em> a channel in each MUX in order to capture the EPG for that MUX, so the entire EPG would be captured in (5 minutes) x (6 MUXes) = 30 minutes, but the SQL transaction rate would be reduced by a factor of 6. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p>In practice the improvement would not be as big as a factor of 6, due to another facet of the way that the EPG is broadcast in the UK: <em>each MUX favours its own channels</em>. If there were no favouritism, each MUX's EPG would occupy 100/6 = 17% of the EPG bandwidth in a MUX. With favouritism, the MUX's own channels will occupy more than 17%, with less being available for the other MUXes. If the MUX's own channels occupied as much as 50% of the bandwidth, that still results in the SQL transaction rate being reduced by a factor of 2; a 30% occupation would result in a reduction by a factor of 3.</p><p></p><p>But the free lunches are not being distributed just yet. The UK has quite a dynamic EPG, meaning that the major broadcasters try to update it with last-minute schedule changes. And indeed, in the four months that I have been using MP, there have been three occasions when MP made two simultaneous recordings of the same programme, but displaced by 5 minutes. These programmes followed the main evening news, which had been extended by 5 minutes due to the amount/severity of the news that day. The broadcasters had updated the EPG, and MP had by coincidence performed an EPG grab before the programmes started, and so recorded each programme twice (at the original scheduled time, and at the revised scheduled time). Live sports programmes also often overrun, affecting subsequent programmes. However, the problem with ignoring the EPG for channels in other MUXes is that these last-minute EPG changes may go unnoticed. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite3" alt=":(" title="Frown :(" loading="lazy" data-shortname=":(" /></p><p></p><p>So, in summary, these EPG grabber settings should eliminate missing EPG highlighting: <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p>(a) Grab when idle.</p><p>(b) Grab when timeshifting/recording.</p><p>(c) Grab only for channels in the same MUX.</p><p>(d) Grab from one 24-hour channel per MUX.</p><p>(e) Store data for all channels in MUX.</p><p></p><p>But the cost is that your EPG may not receive last-minute schedule changes. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite3" alt=":(" title="Frown :(" loading="lazy" data-shortname=":(" /></p><p></p><p>-- from CyberSimian in the UK</p><p></p><p>Edit: Added (d) and (e) for completeness.</p></blockquote><p></p>
[QUOTE="CyberSimian, post: 1120885, member: 141969"] In my previous post I described the problem that I noticed for the first time last week, namely [I]vanishing EPG highlighting[/I]. In this post I want to describe a workaround for the problem that I noticed soon after starting to use MP several months ago, namely [I]missing EPG highlighting[/I]. This workaround may (or may not) also fix the problem of vanishing EPG highlighting. First let us have a recap of where we are with this problem: (1) This thread is but the most recent of several earlier threads concerning this problem (see earlier post). (2) Someone in an earlier thread (not me!) wondered if the problem was caused by the SQL query timing out. (3) [USER=57999]@RobNorthcott[/USER] commented that he was experiencing this problem on an HTPC that he considered "weak", and I commented that my HTPC had a slow operating-system disk (the one used for the SQL databases). (4) [USER=82144]@mm1352000[/USER] examined Rob's logs and observed that his system was grabbing the EPG at the time of the problem. (5) The next time this problem occurred on my system, I examined the TV Server logs and also found that EPG grabbing was occurring at that time. So the indications seem to be that the problem occurs when the system is grabbing the broadcast EPG on a "weak" HTPC. Some weeks ago I modified my EPG-grabbing settings in order to cure an unrelated problem (with help from mm :)); see this thread: [url]https://forum.team-mediaportal.com/threads/recording-failed-to-start.128150/[/url] I ended up with: grab when idle, grab when timeshifting/recording, grab from one 24-hour channel per MUX. However, we did not discuss the [B]Grab EPG only for channels on same transponder[/B] setting, and it is enabling this setting that seems to avoid the problem of missing EPG highlighting. So what is going on here? The reason that I believe this works for the UK EPG is the way in which the data is transmitted. Instead of broadcasting the entire EPG for channel 1, followed by the entire EPG for channel 2, and so on, the data for different channels is [I]interleaved[/I]. Consequently, if the data for channels in other MUXes is ignored, it significantly reduces the rate at which SQL updates are generated, and hence reduces the load on a "weak" system. If (say) it takes 5 minutes to transmit once the entire EPG for the 6 SD MUXes in the UK, grabbing the EPG for all MUXes would capture the entire EPG in just 5 minutes, but produce a very high SQL transaction rate. :( In contrast, ignoring the EPG for channels in other MUXes means that the EPG Grabber must tune [I]in turn[/I] a channel in each MUX in order to capture the EPG for that MUX, so the entire EPG would be captured in (5 minutes) x (6 MUXes) = 30 minutes, but the SQL transaction rate would be reduced by a factor of 6. :) In practice the improvement would not be as big as a factor of 6, due to another facet of the way that the EPG is broadcast in the UK: [I]each MUX favours its own channels[/I]. If there were no favouritism, each MUX's EPG would occupy 100/6 = 17% of the EPG bandwidth in a MUX. With favouritism, the MUX's own channels will occupy more than 17%, with less being available for the other MUXes. If the MUX's own channels occupied as much as 50% of the bandwidth, that still results in the SQL transaction rate being reduced by a factor of 2; a 30% occupation would result in a reduction by a factor of 3. But the free lunches are not being distributed just yet. The UK has quite a dynamic EPG, meaning that the major broadcasters try to update it with last-minute schedule changes. And indeed, in the four months that I have been using MP, there have been three occasions when MP made two simultaneous recordings of the same programme, but displaced by 5 minutes. These programmes followed the main evening news, which had been extended by 5 minutes due to the amount/severity of the news that day. The broadcasters had updated the EPG, and MP had by coincidence performed an EPG grab before the programmes started, and so recorded each programme twice (at the original scheduled time, and at the revised scheduled time). Live sports programmes also often overrun, affecting subsequent programmes. However, the problem with ignoring the EPG for channels in other MUXes is that these last-minute EPG changes may go unnoticed. :( So, in summary, these EPG grabber settings should eliminate missing EPG highlighting: :) (a) Grab when idle. (b) Grab when timeshifting/recording. (c) Grab only for channels in the same MUX. (d) Grab from one 24-hour channel per MUX. (e) Store data for all channels in MUX. But the cost is that your EPG may not receive last-minute schedule changes. :( -- from CyberSimian in the UK Edit: Added (d) and (e) for completeness. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Electronic Program Guide
Scheduled recordings not always highlighted in guide
Contact us
RSS
Top
Bottom