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
Quality Assurance
Bugreports
Archive
Video & Audio Stuttering for short period of time for LiveTV only after S3 or S5
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: 1141713" data-attributes="member: 141969"><p>Thank you for correcting my misunderstanding of this timeout. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite24" alt="(y)" title="Thumbs Up (y)" loading="lazy" data-shortname="(y)" /></p><p></p><p></p><p></p><p>That is interesting. As marttoma had had some success with timeshift grabbing disabled, I thought that I would try that. My TV was off, but the HTPC was recording a programme, and was overdue for an idle EPG grab. I made a note of the time interval between the recording ending and the HTPC hibernating; it took <strong>90 minutes</strong>. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite9" alt=":eek:" title="Eek! :eek:" loading="lazy" data-shortname=":eek:" /></p><p></p><p>I am using MP 1.9.0 pre with debug logs, so I had a look at the TV Server log (attached). You can see that the idle grabber grabbed from 8 MUXes, with each MUX timing out after 10 minutes. So the smart limit on grabbing was never triggered. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite5" alt=":confused:" title="Confused :confused:" loading="lazy" data-shortname=":confused:" /> The quote from the ETSI document suggests that the EPG should have been complete after 300 seconds, so with a further 60 seconds for no new EPG data to be encountered, idle grabbing should have stopped after 6 minutes.</p><p></p><p>The UK DVB-T system has acquired many more channels over the years (possibly more than originally envisaged when the ETSI document was written), so perhaps the 300 seconds is now too short for a complete EPG grab. This is why I postulated grabbing for 60 minutes, with the grab ending after perhaps 12 minutes. I will try 60 minutes and see how long it takes. <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 couple of other points:</p><p></p><p>(1) From the log, the grab from <em>each</em> MUX seems to include both SD channels and HD channels. This is contrary to my previous understanding that the SD MUXes did not contain the EPG for the HD channels. So it looks as though in the UK any MUX can be used. However, I think that it is still true that the HD EPG is transmitted in an encoded form, which is why WMC can display the EPG for the SD channels, but not HD channels.</p><p></p><p>(2) If you look at what PowerScheduler is doing, there seems to be a window for something horrible to happen. During the EPG grab, a tuner is active and PowerScheduler correctly detects every 15 seconds that the system should not sleep/hibernate. But when the grab for a MUX ends, on my system it takes 90 seconds to update the SQL database(s), <em>during which time PowerScheduler thinks that it is OK to sleep/hibernate</em>. Surely there is a check missing here? PowerScheduler should be checking whether SQL updates are being performed and (if they are) prevent sleep/hibernation.</p><p></p><p>You may think that this is academic, but on my system I use a very short hibernation timeout, controlled by my own application. With WMC I used a hibernation timeout of 10 seconds, but that does not work with MP because of PowerScheduler's 15 second heartbeat. I currently use a timeout of 1 minute, but that results in recording failures about 5% of the time because of another window when PowerScheduler fails to prevent sleep/hibernation (as the recording is just about to start). So I use 1 minute normally, and 5 minutes for unattended recordings. I have never noticed a problem from this sleep/hibernation window at the end of grabbing, so perhaps it is benign. Nevertheless, one must conclude that PowerScheduler's processing is not "watertight".</p><p></p><p>-- from CyberSimian in the UK</p><p></p><p>Attached is the TV Server log; look at entries for 2015-07-03:</p><p></p><p>15:55:06.619 EPG grabbing initialised</p><p>15:55:10.099 Grabbing starts on "BBC1 HD"</p><p>16:05:10.357 Grabbing times out</p><p>16:05:11.283 Database update starts</p><p>16:06:43.491 Database update ends</p><p></p><p>This is then repeated for each of the other 7 MUXes.</p></blockquote><p></p>
[QUOTE="CyberSimian, post: 1141713, member: 141969"] Thank you for correcting my misunderstanding of this timeout. (y) That is interesting. As marttoma had had some success with timeshift grabbing disabled, I thought that I would try that. My TV was off, but the HTPC was recording a programme, and was overdue for an idle EPG grab. I made a note of the time interval between the recording ending and the HTPC hibernating; it took [b]90 minutes[/b]. :eek: I am using MP 1.9.0 pre with debug logs, so I had a look at the TV Server log (attached). You can see that the idle grabber grabbed from 8 MUXes, with each MUX timing out after 10 minutes. So the smart limit on grabbing was never triggered. :confused: The quote from the ETSI document suggests that the EPG should have been complete after 300 seconds, so with a further 60 seconds for no new EPG data to be encountered, idle grabbing should have stopped after 6 minutes. The UK DVB-T system has acquired many more channels over the years (possibly more than originally envisaged when the ETSI document was written), so perhaps the 300 seconds is now too short for a complete EPG grab. This is why I postulated grabbing for 60 minutes, with the grab ending after perhaps 12 minutes. I will try 60 minutes and see how long it takes. :) A couple of other points: (1) From the log, the grab from [i]each[/i] MUX seems to include both SD channels and HD channels. This is contrary to my previous understanding that the SD MUXes did not contain the EPG for the HD channels. So it looks as though in the UK any MUX can be used. However, I think that it is still true that the HD EPG is transmitted in an encoded form, which is why WMC can display the EPG for the SD channels, but not HD channels. (2) If you look at what PowerScheduler is doing, there seems to be a window for something horrible to happen. During the EPG grab, a tuner is active and PowerScheduler correctly detects every 15 seconds that the system should not sleep/hibernate. But when the grab for a MUX ends, on my system it takes 90 seconds to update the SQL database(s), [i]during which time PowerScheduler thinks that it is OK to sleep/hibernate[/i]. Surely there is a check missing here? PowerScheduler should be checking whether SQL updates are being performed and (if they are) prevent sleep/hibernation. You may think that this is academic, but on my system I use a very short hibernation timeout, controlled by my own application. With WMC I used a hibernation timeout of 10 seconds, but that does not work with MP because of PowerScheduler's 15 second heartbeat. I currently use a timeout of 1 minute, but that results in recording failures about 5% of the time because of another window when PowerScheduler fails to prevent sleep/hibernation (as the recording is just about to start). So I use 1 minute normally, and 5 minutes for unattended recordings. I have never noticed a problem from this sleep/hibernation window at the end of grabbing, so perhaps it is benign. Nevertheless, one must conclude that PowerScheduler's processing is not "watertight". -- from CyberSimian in the UK Attached is the TV Server log; look at entries for 2015-07-03: 15:55:06.619 EPG grabbing initialised 15:55:10.099 Grabbing starts on "BBC1 HD" 16:05:10.357 Grabbing times out 16:05:11.283 Database update starts 16:06:43.491 Database update ends This is then repeated for each of the other 7 MUXes. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Quality Assurance
Bugreports
Archive
Video & Audio Stuttering for short period of time for LiveTV only after S3 or S5
Contact us
RSS
Top
Bottom