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
Micro stutter on one particular channel during LIVE TV (Solved because: Probably hardware related)
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="mm1352000" data-source="post: 1168747" data-attributes="member: 82144"><p>Thank you for your understanding. <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>It looks like there could be a combination of causes here.</p><p></p><p>In the earlier log files there are:</p><ol> <li data-xf-list-type="ol">Continuity errors in the TsWriter log file. In other words, the stream that TV Server was receiving was already missing parts. Continuity errors are usually caused by signal strength/quality or storage access speed (eg. too high latency) issues. In your case it is also possible that they might be caused by decryption issues. These are direct causes of stutter, pixellation etc.<br /> </li> <li data-xf-list-type="ol">A PCR (program clock reference) jump in the TsWriter log file. In my experience these are relatively rare. They may or may not indicate that the channel provider is not encoding the timings for the channel properly. Failure to encode timing properly can result in decoding problems such as the micro-stutter that you described.</li> <li data-xf-list-type="ol">Late video/audio errors in the TsReader log file. These are direct indicators of micro-stutter and could be connected to (2) and (4).</li> <li data-xf-list-type="ol">Late samples and dropped frames in the EVR log file. These are direct indicators of micro-stutter and could be connected to (2) and (3).</li> </ol><p>In the latest log files there are no issues in the TsWriter log, but still:</p><ol> <li data-xf-list-type="ol">"PES 0-0-1" errors in the TsReader log file. These indicate that parts of the stream were sometimes still encrypted when they reached TsReader. This may or may not be a problem.<br /> </li> <li data-xf-list-type="ol">A late audio error in the TsReader log file. As above: this is a direct indicator of micro-stutter.</li> <li data-xf-list-type="ol">Late samples and dropped frames in the EVR log file. As above: this is a direct indicator of micro-stutter.</li> </ol><p></p><p>So, how to solve the problem?</p><p></p><p>First, I would strongly recommend to untick "single seat setup: force RTSP usage" in MP Configuration -> TV/radio -> advanced options as shown here:</p><p><a href="http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/141_Configuration/MediaPortal_Configuration/22_TV/Advanced_Options" target="_blank">http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/141_Configuration/MediaPortal_Configuration/22_TV/Advanced_Options</a></p><p></p><p>I can't think of any reason why you'd want to enable that option. Most likely it can only cause problems for you by unnecessarily increasing traffic through the network interface/stack.</p><p></p><p>Second, if the above change doesn't help, I'd recommend to increase the TsReader "BufferingDelayInMilliSeconds" setting in the registry (HKEY_CURRENT_USER\Software\Team MediaPortal\TsReader). Overriding that value can help with the late video/audio samples indicated by the TsReader and EVR log files.</p><p></p><p>Finally, despite what you said, I would recommend to avoid using NAS for time-shifting (or recording) if possible. I know that you said that there was no difference between using the NAS and SSD, but if there are multiple causes for the micro-stutter (as I suspect) then you wouldn't have seen any difference until you eliminated the other causes as well.</p><p></p><p></p><p>Please don't hesitate to ask if any of the above information or recommendations are not clear. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p></blockquote><p></p>
[QUOTE="mm1352000, post: 1168747, member: 82144"] Thank you for your understanding. :) It looks like there could be a combination of causes here. In the earlier log files there are: [LIST=1] [*]Continuity errors in the TsWriter log file. In other words, the stream that TV Server was receiving was already missing parts. Continuity errors are usually caused by signal strength/quality or storage access speed (eg. too high latency) issues. In your case it is also possible that they might be caused by decryption issues. These are direct causes of stutter, pixellation etc. [*]A PCR (program clock reference) jump in the TsWriter log file. In my experience these are relatively rare. They may or may not indicate that the channel provider is not encoding the timings for the channel properly. Failure to encode timing properly can result in decoding problems such as the micro-stutter that you described. [*]Late video/audio errors in the TsReader log file. These are direct indicators of micro-stutter and could be connected to (2) and (4). [*]Late samples and dropped frames in the EVR log file. These are direct indicators of micro-stutter and could be connected to (2) and (3). [/LIST] In the latest log files there are no issues in the TsWriter log, but still: [LIST=1] [*]"PES 0-0-1" errors in the TsReader log file. These indicate that parts of the stream were sometimes still encrypted when they reached TsReader. This may or may not be a problem. [*]A late audio error in the TsReader log file. As above: this is a direct indicator of micro-stutter. [*]Late samples and dropped frames in the EVR log file. As above: this is a direct indicator of micro-stutter. [/LIST] So, how to solve the problem? First, I would strongly recommend to untick "single seat setup: force RTSP usage" in MP Configuration -> TV/radio -> advanced options as shown here: [URL]http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/141_Configuration/MediaPortal_Configuration/22_TV/Advanced_Options[/URL] I can't think of any reason why you'd want to enable that option. Most likely it can only cause problems for you by unnecessarily increasing traffic through the network interface/stack. Second, if the above change doesn't help, I'd recommend to increase the TsReader "BufferingDelayInMilliSeconds" setting in the registry (HKEY_CURRENT_USER\Software\Team MediaPortal\TsReader). Overriding that value can help with the late video/audio samples indicated by the TsReader and EVR log files. Finally, despite what you said, I would recommend to avoid using NAS for time-shifting (or recording) if possible. I know that you said that there was no difference between using the NAS and SSD, but if there are multiple causes for the micro-stutter (as I suspect) then you wouldn't have seen any difference until you eliminated the other causes as well. Please don't hesitate to ask if any of the above information or recommendations are not clear. :) [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Quality Assurance
Bugreports
Archive
Micro stutter on one particular channel during LIVE TV (Solved because: Probably hardware related)
Contact us
RSS
Top
Bottom