Multiseat: A lot of stuttering, artifacts, pixelation, freezes with RTSP/UNC (2 Viewers)

[breese]

Or download baretail
Great application for watching logs on a windows box
http://www.baremetalsoft.com/?app=BareTail&ver=3.50a&build=2006-11-02

 

[Owlsroost]

I regularly have 'live' TsReader log files open in a text editor with no problems at all. If TsReader can't write to the log file it should just discard the logging data - it shouldn't stop it working.

If you ended up back at the TV 'connection screen' it suggests there might be a networking problem.....

TsReader does read files in reasonable chunks (I think 512KB - don't have the code in front of me at the moment). If there is less data available in the file i.e. we have reached the end, then Windows just returns what is available - this of course happens all the time when timeshifting close to the 'live' point.

 

[HomeY]

I regularly have 'live' TsReader log files open in a text editor with no problems at all.

Same here. Never had issues.

 

[HTPCSourcer]

If you ended up back at the TV 'connection screen' it suggests there might be a networking problem.....

Just repeated the activity using Notepad++ - everything working normal, i.e. no break-off. I can hear the football game going on in the living

Same here. Never had issues.

Me neither until earlier today. Things work alright now.

But back to the core of this thread. I am not really satisfied with my system's Live TV performance because just like @Snoopy87 I am suffering of audio and picture interruptions. For the first time since I've been using MediaPortal, which goes back to 2008, I begin thinking about reactivating the Sky SAT Receiver. I recall earlier MePo versions with no problem in Live TV. Now I did change hardware this summer and therefore one needs to be cautious to not draw false conclusions.

It is frustrating though that there appears to be no cure for the stuttering disease.

 

[HomeY]

It is frustrating though that there appears to be no cure for the stuttering disease.

Did you have a look @ this WIki?
http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/16_Support/Troubleshooting/Stuttering_Playback

Easiest way to test if it's hardware or software related is to downgrade to a previous version. The most simple way to do that is extract the 2 packages-xx with 7zip from the DeployTool installer (deploy folder) and use those to downgrade your install.
As an extra 'Backup' you can simply zip up both Team MediaPortal folders (ProgFiles & ProgData) and unzip them after testing previous versions so you have your working install back.

 

[HomeY]

@HTPC_Sourcer
Just remembered i had another 'Network issue' related post bookmarked which might give you some more pointers for your problem:
https://forum.team-mediaportal.com/threads/network-speed-problems.109583/page-2#post-886452

 

[HTPCSourcer]

Thanks. A really comprehensive tutorial.

Maybe I have been conveying a wrong picture. It's not that one cannot watch TV, it's simply that the occasional short audio interruptions are annoying. I did just apply a change to some security settings of the server GPO with the funny result that I am now getting 50x more signature errors being logged but the TV result feels better. On top of that I activated the option in the config to not drop discontinued packages. The quantitative result after some 10 min of encrypted 1080i Sky football is ~40.000 frames drawn with 17 drops of which 6 occurred at the channel start, hence normal.

How does this ratio of 1:4000 frame drop rate compared to other people's experience?

I do admit that these ridiculous error messages keep nagging on me though. Something to work on to make them disappear

 

[Owlsroost]

Thanks. A really comprehensive tutorial.

Maybe I have been conveying a wrong picture. It's not that one cannot watch TV, it's simply that the occasional short audio interruptions are annoying. I did just apply a change to some security settings of the server GPO with the funny result that I am now getting 50x more signature errors being logged but the TV result feels better. On top of that I activated the option in the config to not drop discontinued packages. The quantitative result after some 10 min of encrypted 1080i Sky football is ~40.000 frames drawn with 17 drops of which 6 occurred at the channel start, hence normal.

How does this ratio of 1:4000 frame drop rate compared to other people's experience?

I do admit that these ridiculous error messages keep nagging on me though. Something to work on to make them disappear

The next version of TsReader will suppress the 'signature error' messages in the log (but I have very little time to work on MP until the weekend, so you'll have to be patient).

A 1:4000 frame drop rate is a bit high - mine is more like 10x better (40000:1), but I run a single-seat system using free-to-air DVB-T/DVB-T2.

 

[HTPCSourcer]

...so you'll have to be patient).

No problem, it's just a message.

The GOP that I implemented yesterday has to do with the signature process and is reported to increase server speed by suppressing the need for signing, which creates a 10-15% overhead. I was quite surprised that after having done this, instead of having occasional invalid signature messages in tsreader.log, the log was virtually flooded with these messages. I am really interested what kind of SMB registry setting leads to these errors being reported by Windows. Could you imagine to provide a registry setting for switching the reporting on and off in tsreader? This way I could continue to investigate. But certainly just a nice-to-have only.

A 1:4000 frame drop rate is a bit high - mine is more like 10x better (40000:1), but I run a single-seat system using free-to-air DVB-T/DVB-T2.

This was just a 10 min watch number and I would need to monitor this over a longer time for different channels to assess if the 1080i in combination with CI decrypting vs. 780p HD and/or SD TV makes a difference. Will report again.

 

[HTPCSourcer]

Hi @Snoopy87 ,

If I understood your initial comments correctly you have a satisfactory experience if client and server are connected via cable, but get lots of disruptions when attempting connection through WiFi.

As @mm1352000 has already pointed out, the architecture of the timeshift process is very much based on a synchronous writing and reading process. One could probably imagine a buffer of several seconds, however at the expense of increasing the waiting time when switching channels because said buffer would need to be filled first.

If you are OK to increase your channel change time, then you may try a beta tsreader that @Owlsroost has posted here. With this version you can define additional buffer time between 0 and 2000 ms in the registry by adjusting the key BufferingDelayInMilliSeconds. Might be worthwile to give 1000 ms a try and see how your local system performs.