Use Kodi buffer (settings) for mythtv data stream

[sumpfralle]

I am using Kodi v17 together with pvr.mythtv (4.12.7+git20161219-2). In general it works really fine.

I am connected to the mythtv server (in another building) via a wifi connection. Sadly this wifi connection gets occassionally saturated for some seconds due to backups and other transfers. During these moments video playback tends to struggle (audio stuttering, pausing for buffering). This can be expected when only a small buffer (few seconds is used).

I followed a kodi wiki article and put the following lines into my local settings file:

$ cat .kodi/userdata/advancedsettings.xml 
<advancedsettings>
  <loglevel>0</loglevel>
  <cache>
    <memorysize>1073741824</memorysize>
    <buffermode>1</buffermode>
    <readfactor>4.0</readfactor>
  </cache>
</advancedsettings>

I expected to see the memory usage of kodi rise significantly while filling the buffer during mythtv video playback. I also expected to see consistently high network traffic after starting video playback while filling the buffer. Both did not happen.

Thus it feels like the pvr.mythtv plugin does not use the above buffer (settings). Maybe there is another way to configure the buffer used by the plugin? Or do I misunderstand something?

[janbar]

Those settings are related to kodi player, not the addon itself. During the playback the addon try to complete what the player/demuxer requires: read some bytes or seek to a specified position in the stream. A stream buffer for the playback doesn t use more than few mega bytes. So you will never see a significant memory growing regarding the global allocated memory by the kodi main processus. Which can be few hundreds mega bytes (300 MB ~ 500 MB).

[janbar]

Now I never have a look how playback buffer is handled by the kodi players. There is different player for the live or the recorded streams. It could be have an issue if entire operation to read bytes is synchonized with others as fill new bytes. May be that's the case and so blocking network reads could affect the flow of playback. But it would be surprising.

[sumpfralle]

Thank you for considering my question!

A stream buffer for the playback doesn t use more than few mega bytes.

With my settings above I tried to increase the buffer to 1 GB (according to the documentation of this setting, this would require 3 GB of raw RAM). Thus I assumed I would notice it :)

Being completely new to kodi's code (and not being used to C++, anyway) I took a look at how other kodi components interact with the cache buffer. I found this one here: DVDInputStreamFile. Here the cache configuration (specifically "buffermode") is evaluated and used for determining the cache-enabled flag for a file open operation (m_pFile->Open(m_item.GetPath(), flags)) with the m_pFile being an instance of a file retrieved via curl (m_pFile = new CFile(); - in case I do not misunderstand this).

I am not sure, whether the cache buffer features are provided by other transports (besides curl), as well. I also do not know the internals of the pvr.mythtv addon. But maybe you can take a look if the retrieval of the mythtv stream could be accomplished by using the CFile class and thus could use the cache without too much additional effort?

Thank you!

[janbar]

The addon is a dynamic lib which is binded by kodi to provide PVR services. So it provides functions according to the PVR api. It can't and it doesn't handle internal structures of kodi. The PVR api defines a set of functions and data structures know by kodi and the addon. So no way. I think your issue concerns kodi, and not the addon.

[sumpfralle]

Thank you for pointing this out!

I took a look at the include directory, that seems to represent (as far as I can tell) the publicly available interface of kodi towards addons (xbmc/addons/kodi-addon-dev-kit/include/kodi). Here I found the following interface definition:

    /*!
     * @brief Open the file with filename via XBMC's CFile. Needs to be closed by calling CloseFile() when done.
     * @param strFileName The filename to open.
     * @param flags The flags to pass. Documented in XBMC's File.h
     * @return A handle for the file, or NULL if it couldn't be opened.
     */
    void* OpenFile(const char* strFileName, unsigned int flags)
    {
      return m_Callbacks->OpenFile(m_Handle->addonData, strFileName, flags);
    }

I assume that the flags parameter can contain the READ_CACHED and READ_NO_CACHE flags, that would control the usage of the kodi's caching.

Being far away from kodi's code, I am just stabbing in the dark with my thoughts. Feel free to ignore the above, if it does not spark any interesting thoughts inside of you.