[dapharsyde]

Hi All - 

I have a 2018 version Abox A1 Max with S905W chipset. 

I've tested a LE 8.2.3 image from kszaq, Kodi 17, which uses MythTV add-on version 4.15.3.  With this combination, 1080p Live TV and Recordings work fine.

When I upgraded to a LE 8.90 image from adamg, Kodi 18, I started experiencing stuttering while playing 1080p Live TV or Recordings with the MythTV add-on, version 5.6.0.  720p Live TV and recordings work fine.  If I play the same 1080p mpg file using the Emby add-on, there is no stuttering, which suggests the issue may lie within the MythTV plugin.

Is it possible to test a 4.x version of the MythTV add-on in Kodi 18?  The repository only lets me install version 5.6.0.  If I could install the older version, this would help me determine if the stuttering was from the MythTV add-on changes, or something else from LE 8.90.

[dapharsyde]

I've noticed that when playing the 1080p mpg clip using the Emby add-on, the file transfer rate is quite fast and the entire file is complete in an instant, allowing smooth playback.  On the other hand, when playing the file via the TV/MythTV add-on, the file transfer is much slower.  It tries to buffer a few seconds, but eventually the playback catches up to the buffer and begins to stutter.

Attempts to mess with cache using advancedsettings.xml has not helped.

Seems that something is limiting the file/data transfer rate when using MythTV.  I saw something in the changelog about http chunking - could this be related to that issue?

[dapharsyde]

Just tested with the NextPVR add-on instead of MythTV, and 1080p Live TV works with no issues.  There must be an issue with the MythTV add-on somewhere.

I'll probably use NextPVR in the meantime, but if anyone can help with me troubleshoot this, I would like to keep trying the MythTV add-on.

[janbar]

Hi, there is no change in the addon relates the stream transfer, between 4.5 and 5.6. The only changes relate adaptation for kodi api. For your case the big change is kodi, so not the addon.
MythTV backend uses its own protocol to transfer stream data. Those data are transfered by block and the rate is limited by the backend itself.
You could check your backend isn't overloaded or its network connection has the required throughput, not overloaded too.
Here until now I haven't any issue with HD stream using a wired network. But currently I use only kodi 17. Soon I will trying kodi 18 when it will be in beta stage.

[janbar]

As I said before after many testing, a wifi connection between kodi and mythtv backend isn't reliable, due to how the backend handles the stream transfer: if the client has claimed to many data , it resumes the transfer for a time.

[dapharsyde]

Hi, there is no change in the addon relates the stream transfer, between 4.5 and 5.6. The only changes relate adaptation for kodi api. For your case the big change is kodi, so not the addon.
MythTV backend uses its own protocol to transfer stream data. Those data are transfered by block and the rate is limited by the backend itself.
You could check your backend isn't overloaded or its network connection has the required throughput, not overloaded too.
Here until now I haven't any issue with HD stream using a wired network. But currently I use only kodi 17. Soon I will trying kodi 18 when it will be in beta stage.

 Hi janbar - I am fairly confident that my mythbackend is not bottled down.  On a kodi 17 instance with the older version of the MythTV addon, it works well with 1080p.  Without any changes to my network or backend, 1080p begins stuttering in kodi 18 using the new addon, v5.6.  Is there any way to install the v4.5 addon in kodi 18?

My backend is still running Myth v28 - I saw the newer version of the addon supports v29, but is that an absolute requirement?

[dapharsyde]

Well I managed to get live 1080p working in an earlier Kodi 18 build, and found exactly when the issue shows up.  Using the milhouse test builds, I've determined that the stuttering issue begins in between builds #0709 (works) and #0710 (doesn't work).

The post about #0710 mentions some updates to the mythtv pvr addon, could those have anything to do with stuttering issues, or is it just a coincidence?

EDIT: Never mind, it looks that the add-on is at version 5.1.1 for both builds #0709 and #0710, so the issue must be caused by something else.  Would you agree?

[dapharsyde]

Build #0710 references a XBMC pull request, which merged in some updates to VideoPlayer, related to buffering.  From what I've read below, is it possible that buffering is now handled by the addon after this change?  So if the MythTV addon doesn't support buffering, it would cause the 1080p Live TV to stutter?  Considering that 1080p Live TV works in the NextPVR addon, I'm still wondering if this may be missing in the MythTV addon.

We were trying some concepts to cut dependencies to platform specific code and features. Seems the API how platforms can extend VideoPlayer stabilizes. With merge of vpupdates we allow platforms to register components into VP. Those are:

- hardware decoders
- hardware related video buffers like dma
- renderers that can handle thos video buffers
- a controller component that defines how VP behaves in different situations

Polling by the UI is continuously reduced.

Next major milestons are cutting dependencies to PVR and GUI.

[dapharsyde]

I've now determined that the buffering is with MPEG-2 streams, both 720p and 1080p.  H.264 streams are ok.  I assume there is more data/buffering required by MPEG-2, so if this VideoPlayer change handed off buffering to the addon, there could be something missing there.

From the pull request - https://github.com/xbmc/xbmc/pull/12212 - FernetMenta writes:
 

This adds video buffers to be used by decoders and renderers. platforms can register custom buffers like dma.
render formats are history, renderers need to check type of video bufferplatforms register

• decoders
  
• renderers
  
• processInfo
  

 
@janbar - Could you please tell me if the MythTV addon needs to be updated for this?

[janbar]

I have to check that. Maybe it could be good to handle buffering in the addon. But for now don't know if it will resolve your issue. MP2 stream 1080p are very heavy for IO.

[dapharsyde]

Hi Janbar - thank you for your response.  FYI I have opened an issue in your github repo over here

Simultaneously, I also have a trac issue opened here, in case this is related to VideoPlayer.  I'm hoping these two sides can come together and figure out what the cause of this issue is, and why the MythTV addon stopped working for heavy i/o streams.

Please let me know if there is any additional information I can help provide.

[janbar]

So, I checked the last addon api , and there is nothing about to handle the buffer for the video player. So your issue is a regression in kodi since the change #12212.

[dapharsyde]

Hi @janbar - 

After enabling additional debug info from the MythTV addon, I found that after the VideoPlayer/VideoBuffer merge, the request block size being made by the MythTV addon is no longer dynamic - instead it only requests only 4096 bytes each time - the log file looks like:

07:42:00.352 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: receive block size (4096)
07:42:00.352 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: data read (4096)
07:42:00.352 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)SendCommand: QUERY_FILETRANSFER 134:REQUEST_BLOCK:4096
07:42:00.359 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)RcvMessageLength: 4
07:42:00.360 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: receive block size (4096)
07:42:00.360 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: data read (4096)
07:42:00.361 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)SendCommand: QUERY_FILETRANSFER 134:REQUEST_BLOCK:4096
07:42:00.368 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)RcvMessageLength: 4
07:42:00.368 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: receive block size (4096)
07:42:00.368 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: data read (4096)
07:42:00.368 T:139768608380672   DEBUG: ffmpeg[7F1E6A40D700]: [mpegts] pid=1364 pes_code=0x1e0
07:42:00.369 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)SendCommand: QUERY_FILETRANSFER 134:REQUEST_BLOCK:4096
07:42:00.380 T:139768608380672   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)RcvMessageLength: 4

Prior to this merge, the debug log shows the MythTV addon requesting blocks up to 32768 bytes.  This allows 1080p mpeg 2 to work smoothly.

07:50:01.542 T:139892982015744   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)RcvBackendMessage: UPDATE_FILE_SIZE 24703 2018-02-23T07:49:57Z 5598076 (4)
07:50:01.591 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)RcvMessageLength: 5
07:50:01.591 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: receive block size (32768)
07:50:01.591 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: data read (32768)
07:50:01.591 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: data read (5792)
07:50:01.591 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: data read (1448)
07:50:01.593 T:139892938344192   DEBUG: Previous line repeats 8 times.
07:50:01.593 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: data read (4348)
07:50:01.593 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)SendCommand: QUERY_RECORDER 1:GET_FILE_POSITION
07:50:01.596 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)RcvMessageLength: 7
07:50:01.597 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)SendCommand: QUERY_FILETRANSFER 137:REQUEST_BLOCK:32768
07:50:01.609 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)RcvMessageLength: 5
07:50:01.609 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: receive block size (32768)
07:50:01.609 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: data read (9596)
07:50:01.609 T:139892938344192   DEBUG: ffmpeg[7F3B5CE58700]: [mpegts] pid=1366 pes_code=0x1bd
07:50:01.609 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)SendCommand: QUERY_FILETRANSFER 137:REQUEST_BLOCK:32768
07:50:01.615 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)RcvMessageLength: 5
07:50:01.615 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: receive block size (32768)
07:50:01.615 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: data read (32768)
07:50:01.616 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)SendCommand: QUERY_FILETRANSFER 137:REQUEST_BLOCK:32768
07:50:01.620 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)RcvMessageLength: 5
07:50:01.621 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: receive block size (32768)
07:50:01.621 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: data read (32768)
07:50:01.621 T:139892938344192   DEBUG: ffmpeg[7F3B5CE58700]: [mpegts] pid=1364 pes_code=0x1e0
07:50:01.621 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)SendCommand: QUERY_FILETRANSFER 137:REQUEST_BLOCK:32768
07:50:01.626 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)RcvMessageLength: 5
07:50:01.626 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: receive block size (32768)
07:50:01.626 T:139892938344192   DEBUG: AddOnLog: MythTV PVR Client: (CPPMyth)TransferRequestBlock: data read (32768)
07:50:01.626 T:139892938344192   DEBUG: ffmpeg[7F3B5CE58700]: [mpegts] pid=1364 pes_code=0x1e0
07:50:01.627 T:139892938344192   DEBUG: ffmpeg[7F3B5CE58700]: [mpegts] PMT: len 55

Let me know if you want to see the complete logs.

[janbar]

I think you found the cause of the issue. 4k per request is too small to get enougth data in time. Probably there is too many roundtrip now.
You could add that in the Track ticket to help the resolving.

But now I have a new question: how it could work without stutthering with addon NextPVR ?

EDIT: I had a look in the NextPVR source, and it seems to have an intermediate buffer to store the streamed data, with a size of 18k. Maybe the reason why it isn't impacted by the issue.

[dapharsyde]

Hi @janbar - 

I have uploaded the full debug logs to the github issue - https://github.com/janbar/pvr.mythtv/issues/94

The trac issue I opened in the Kodi repository was closed and marked as a 3rd party issue.

It sounds like we've found the source of the issue and the reason why NextPVR continues to work even after the patch.  Please let me know if you are able to look at this and provide a patch to the MythTV addon.  I would be happy to test it out.

Thank you!