Issues with live TV on client PC (2 Viewers)

[T^2]

Also note that since messing with the BufferingDelayInMilliSeconds registry entry values, live TV has gotten much worse on the client machine even though the setting has been returned to 0.

The setting only affects TsReader (and it's read by TsReader each time play starts) so I think that's just coincidence. The TsReader log tells you what the setting is e.g. '--- Buffering delay = 0 ms' or '--- Buffering delay = 2000 ms' if you want to check.

I'd try the 'debug' UNC paths option for TV as well to see if it works better than the default RTSP mode - see https://forum.team-mediaportal.com/threads/tvplugin-avoiding-rtsp-in-multiseat-mode-test-plz.36735/

What you have in the client logs are typical RTSP 'lost packet' problems (which create continuity errors => stutters/corrupted video). What sort of networking are you using ?

Nothing special on the the networking front. The server and client machines are both connected to the same router via cat5/cat6. Simple WORKGROUP setup with file shares etc....

I read the post in the thread that you linked to. It leads to a few questions. So based on this:

===================================================================

EDIT: The modifications in this thread are now included in MP.

For more information, see http://wiki.team-mediaportal.com/1_...diaPortal_Configuration/22_TV/5_Debug_Options and https://forum.team-mediaportal.com/t...rtsp-in-multiseat-mode-test-plz.36735/page-28

=======================================================

I'm wondering it it's still necessary to do this (and if so which parts?):

open "mediaportal.xml" and insert this new "usertsp" tag.

<section name="tvservice">
<entry name="usertsp">no</entry>

optionally insert "recordingpath" and "timeshiftingpath" tags.
<entry name="recordingpath">I:\DVB-Capture</entry>
<entry name="timeshiftingpath">I:\DVB-Timeshifting</entry>

If these paths are defined then they will be used instead of the equivalent UNC path.
One problem is that those folders will only work if all cards on the server is timeshifting to the same folder.
The same goes for recording folders.
If you only want to use UNC path, then omit the 2 XML keys, or use empty strings in name="".
To use these paths, please map a network drive on each client.
In this example it's drive letter I.

Or do I simply setup do this?:

You need to start configuration.exe from the command line or edit the shortcut on your desktop (or wherever).

1. Open the start menu.
2. Type cmd, hit enter.
3. Type "c:\Program Files (x86)\Team MediaPortal\MediaPortal\Configuration.exe" /DebugOptions (assuming that is the path to MP on your PC and include the quotes) and hit enter.

The debug options are a sub-section under "TV".

And then setup the UNC paths as noted in http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/141_Configuration/MediaPortal_Configuration/22_TV/5_Debug_Options?[DOUBLEPOST=1389271942][/DOUBLEPOST]Or do I still need to do this regardless?:

open "mediaportal.xml" and insert this new "usertsp" tag.

<section name="tvservice">
<entry name="usertsp">no</entry>

Edit: Ok... skimmed through the thread. So it's an either or proposition. Either make the changes to the .xml file or add /DebugOptions to the .exe and then change the UNC paths in the GUI.

 

[mm1352000]

What you have in the client logs are typical RTSP 'lost packet' problems (which create continuity errors => stutters/corrupted video). What sort of networking are you using ?

Yes... except that if it is a network issue, why should it matter which HDD is used for timeshifting? He did say that when he used the SSD, the client was also okay.

 

[T^2]

What you have in the client logs are typical RTSP 'lost packet' problems (which create continuity errors => stutters/corrupted video). What sort of networking are you using ?

Yes... except that if it is a network issue, why should it matter which HDD is used for timeshifting? He did say that when he used the SSD, the client was also okay.

Good question.... Which is a bummer... I was all excited that I had something (perhaps a solution) to try out tonight when I got home. So, it didn't dawn on me to stop and think about it for a second. Now I'm starting to think that pursuing the RTSP workaround will likely end up being fruitless. With that in mind, I'm thinking I'm going to be wanting to put that spare HDD in the server machine tonight (use it for buffering). Only problem is - the "better half". She may be watching TV with the server machine tonight - tying it up... Or worse, she may want me to sit at the table all night and listen to her talk. I've already been taking major hits in the WAF score. The WAF is tough. If it doesn't "just work" - or be perceived to "just work" - like a cable box soon it could put the whole project in jeopardy. And me playing around doing all this troubleshooting lately has been causing me some blow-back (I've caused some disruptions in her viewing pleasure... BSOD's etc... Plus she's accusing me of becoming obsessed with all this stuff... and she's dropping hints that I need to be spending more time on "us" etc...). I was thinking that I could at least do my tinkering with the RTSP workaround on the client machine in the other room tonight without disturbing the Boss (at least in theory anyway). Now hitting her with the notion that I want to crack the server machine open tonight and install another HDD... Man-o-man... The WAF will take a big hit...

...Maybe I'll get lucky and she'll have to work late.

 

[mm1352000]

Ohhh, don't get me wrong - I think the RTSP workaround (UNC) is worth trying. It changes the way the timeshift file is read.
My point to Owlsroost was that I don't think the network is dropping packets.

 

[T^2]

Double bummer... Got a chance to do the RTSP workaround... (Boss isn't home yet). No change still un-watchable. Same symptoms. Attached my logs...[DOUBLEPOST=1389309245][/DOUBLEPOST]Wait.... I may have spoken too soon....

 

[T^2]

So... First problem... Somehow Software Deinterlacing got turned on the LAV filter. Corrected that.

Tried again... Live TV looks good so far... Noticed that it doesn't appear to have hardware acceleration with the LAV filter. Will try the Microsoft DTV-DVD Video Decoder.

 

[mm1352000]

Tried again... Live TV looks good so far... Noticed that it doesn't appear to have hardware acceleration with the LAV filter. Will try the Microsoft DTV-DVD Video Decoder.

LAV doesn't support DXVA v1. That should only be relevant if you're using XP or a reasonably old GPU.

 

[Owlsroost]

add /DebugOptions to the .exe and then change the UNC paths in the GUI.

That's the correct route.

 

[T^2]

Tried again... Live TV looks good so far... Noticed that it doesn't appear to have hardware acceleration with the LAV filter. Will try the Microsoft DTV-DVD Video Decoder.

LAV doesn't support DXVA v1. That should only be relevant if you're using XP or a reasonably old GPU.

Noted... Also noted that HA works in LAV with NVidia CUVID... Don't know what issues come with NVidia's implementation... So I just switched everything the Microsoft DTV-DVD Video Decoder...

Any advantages of LAV over Microsofts DTV-DTD Video Decoder?[DOUBLEPOST=1389311565][/DOUBLEPOST]

add /DebugOptions to the .exe and then change the UNC paths in the GUI.

That's the correct route.

Yup... got that working....

Problem now... The Boss is home... Progress will slow greatly I suspect...

 

[Owlsroost]

So... First problem... Somehow Software Deinterlacing got turned on the LAV filter. Corrected that.

Tried again... Live TV looks good so far... Noticed that it doesn't appear to have hardware acceleration with the LAV filter. Will try the Microsoft DTV-DVD Video Decoder.

Yes, the according to what's in the TsReader log the video decoding is taking too long - presumably because it's not using DXVA and hardware deinterlacing (and the CPU can't cope with software decoding of full HD 1080i TV)