Kodi Community Forum

@CaptainT

"New versions are on their way to the official repo"

Many thanks for updating the plugin but the new version still isn't available for download. Do they normally take this long?

(2019-03-25, 10:05)linknet Wrote: [ -> ]Many thanks for updating the plugin but the new version still isn't available for download. Do they normally take this long?

No, they normally do not take that long. Seems to be some sort of delay at the Kodi Devs responsible for the official repo. Perhaps they had a well deserved weekend off.

(2019-03-25, 13:11)CaptainT Wrote: [ -> ]

(2019-03-25, 10:05)linknet Wrote: [ -> ]Many thanks for updating the plugin but the new version still isn't available for download. Do they normally take this long?

No, they normally do not take that long. Seems to be some sort of delay at the Kodi Devs responsible for the official repo. Perhaps they had a well deserved weekend off.  

Brilliant now fully working.
Many thanks

Greetings,

Updated to 3.0.43 on LibreELEC 9.0.1 (RPi2.arm) and Episodes are once again displayed for programs selected from "Programme List A-Z"

Just wanted to express my appreciation to @CaptainT (and all contributors) for their ongoing effort and support of this amazing add-on.

Thanks.

I wan't to be able to search iplayer from within the Chorus WebUI, does anyone know the search URL needed to do that?

Chorus readme Wrote:If you wish to search content provided by an add-on that isn't included with Chorus, you can add your own custom add-on search which tells Chorus how it can search for the content provided by that add-on.
To add a custom search, you need to know what url the add-on is using internally to provide the search results. This isn't always easy or obvious to find out and may involve looking through the add-on code or kodi logs to determine the correct url to use. Chorus will substitute the token [QUERY] with the search term.

Examples of add-on search urls

YouTube:

Code:

plugin://plugin.video.youtube/search/?q=[QUERY]

SoundCloud:

Code:

plugin://plugin.audio.soundcloud/search/query/?q=[QUERY]

Radio:

Code:

plugin://plugin.audio.radio_de/stations/search/[QUERY]

MixCloud:

Code:

plugin://plugin.audio.mixcloud/?mode=30&key=cloudcast&offset=0&query=[QUERY]

I've tried the examples, and variants of, and looked through the various iplayer .py files, but I can't figure out the URL to use.

(2019-04-04, 00:22)FannyCradock Wrote: [ -> ]I wan't to be able to search iplayer from within the Chorus WebUI, does anyone know the search URL needed to do that?

Chorus readme Wrote:Examples of add-on search urls

YouTube:

Code:

plugin://plugin.video.youtube/search/?q=[QUERY]

SoundCloud:

Code:

plugin://plugin.audio.soundcloud/search/query/?q=[QUERY]

Radio:

Code:

plugin://plugin.audio.radio_de/stations/search/[QUERY]

MixCloud:

Code:

plugin://plugin.audio.mixcloud/?mode=30&key=cloudcast&offset=0&query=[QUERY]

I've tried the examples, and variants of, and looked through the various iplayer .py files, but I can't figure out the URL to use.   

Try this:

or this:

Not sure this is enough, but it is the correct mode to get into search. It may need dummy urls, titles or the likes.

I installed v3.0.43 for kodi krypton 17.6. All working -- default addon settings (BBCiD off, etc - all left at default). Windows 8.1 x64. Intel i5-6500, 16GB RAM. I have a 76 Mbps internet connection which is very stable (easily getting 7+ Mbytes/s download speed from most websites).

If I go to the iPlayer website with a browser (Chrome) and play streams then everything works smoothly and fully for hours for the highest resolution and bitrate - nice HD looking content. No problems whatsoever.

However, with Kodi via this addon, it stops every few minutes, presumably to buffer -- i have to skip backwards a few seconds and then it works again for a few minutes, and then again stops, and so on and so forth. It's annoying enough to the point where it's practically unusable for a watching experience.

This can't be normal, can it?

I did read the info about buffering.

I added and edited my advancedsettings.xml file (see below) to set caching/buffering all streams up to 512MB (I have 16GB RAM) and read factor of 10.0 (I tried 5.0 and 2.0 as well). Nothing seemed to affect it. When I watch other network streams from my LAN I can see the buffering happening in the play bar, a gray bar advancing ahead of the green bar. That doesn't happen using this plugin.

Is there a fix?

My full advancedsettings.sml from C:\Users\MYNAME\AppData\Roaming\Kodi\userdata\advancedsettings.xml:

xml:


<?xml version="1.0" encoding="UTF-8"?>

<advancedsettings>

    <imageres>720</imageres>

    <fanartres>1080</fanartres>

    <packagefoldersize>200</packagefoldersize>

    <seeksteps>5, 10, 15, 20, 30, 60, 120, 180, 300</seeksteps> <!-- Seek steps, introduced in v15 -->

    <video>

        <subsdelayrange>60</subsdelayrange>  <!-- Delay range for subtitles, in seconds. -->

        <audiodelayrange>60</audiodelayrange>  <!-- Delay range for audio/video sync, in seconds. -->

        <smallstepbackseconds>5</smallstepbackseconds>  <!-- Length of the small skip back when playing a video -->

        <usetimeseeking>true</usetimeseeking>  <!-- Whether to use time based or percentage based seeking. -->

        <timeseekforward>5</timeseekforward>  <!-- Time to seek forward in seconds when doing a short seek.  Defaults to 30. -->

        <timeseekbackward>-5</timeseekbackward>  <!-- Time to seek backward in seconds when doing a short seek.  Defaults to -30. -->

        <timeseekforwardbig>30</timeseekforwardbig>  <!-- Time to seek forward in seconds when doing a long seek.  Defaults to 600 (10 minutes). -->

        <timeseekbackwardbig>-30</timeseekbackwardbig>  <!-- Time to seek forward in seconds when doing a long seek.  Defaults to -600 (10 minutes). -->

        <percentseekforward>2</percentseekforward>  <!-- Amount to seek forward as a percentage, when doing a short seek.  Defaults to 2. -->

        <percentseekbackward>-2</percentseekbackward>  <!-- Amount to seek backward as a percentage, when doing a short seek.  Defaults to -2. -->

        <percentseekforwardbig>10</percentseekforwardbig>  <!-- Amount to seek forward as a percentage, when doing a long seek.  Defaults to 10. -->

        <percentseekbackwardbig>-10</percentseekbackwardbig>  <!-- Amount to seek forward as a percentage, when doing a long seek.  Defaults to -10. -->

    </video>

    <cache>

        <!-- http://wiki.xbmc.org/index.php?title=HOW...ideo_cache -->

        <buffermode>1</buffermode>  <!-- 0=all internet, 1=all streams (including local), 2=internet streams, 3=none -->

        <memorysize>512000000</memorysize>  <!-- Cache in bytes, in RAM if >0 (RAM used is 3x this value), 0=on disk, entire video -->

        <readfactor>5.0</readfactor>  <!-- cache fill rate: 1=little above what's needed to play; higher values fill the cache quicker -->

    </cache>

    <videoextensions>

        <remove>.rar|.001</remove>

    </videoextensions>

</advancedsettings>

Settings in advancedsettings.xml only affect the standard player, they do not change the behaviour of inputstream.adaptive, which is used for DASH playback.

Try changing the add-on stream settings. I suggest switching off autoplay to find the best CDN for your location. Also try DASH and HLS as stream protocol. One may work better than the other from your location.

The main issue here is adaptive bitrate switching, which is still missing in inputstream.adaptive. As long as this is not implemented, buffering issues can be annoying.

(2019-04-14, 20:55)CaptainT Wrote: [ -> ]Settings in advancedsettings.xml only affect the standard player, they do not change the behaviour of inputstream.adaptive, which is used for DASH playback.

Try changing the add-on stream settings. I suggest switching off autoplay to find the best CDN for your location. Also try DASH and HLS as stream protocol. One may work better than the other from your location.

The main issue here is adaptive bitrate switching, which is still missing in inputstream.adaptive. As long as this is not implemented, buffering issues can be annoying.

Thanks, I'll try those. But, regardless of the settings, are you saying that playing via your addon will always be more error prone compared to playing directly via browser?

"Catchup CDN source" was already on "Any".

If I switch off "Play streams automatically using these settings" then I still need to choose an option for "Stream protocol" and "Catchup CDN source". Currently those are "HLS" and "Any". Does "Any" mean it will try and find the best CDN for my location or do you suggest to take each of those in turn as well to find if there is one that works?

I would have thought HLS is better buffering and bandwidth wise. I'll try DASH as well.

(2019-04-14, 21:45)normadize Wrote: [ -> ]Thanks, I'll try those. But, regardless of the settings, are you saying that playing via your addon will always be more error prone compared to playing directly via browser?

"Catchup CDN source" was already on "Any".

If I switch off "Play streams automatically using these settings" then I still need to choose an option for "Stream protocol" and "Catchup CDN source". Currently those are "HLS" and "Any". Does "Any" mean it will try and find the best CDN for my location or do you suggest to take each of those in turn as well to find if there is one that works?

I would have thought HLS is better buffering and bandwidth wise. I'll try DASH as well. 

The underlying issue is, that Kodi is currently unable to switch streams (or even bitrates in the same stream) on the fly. This is what iPlayer in a web browser does. If there is a temporary congestion in your area, it will simply reduce the bitrate (and quality) of the stream temporarily. But it will continue to play. Kodi is unable to do that according to my knowledge. So if the selected stream runs low on buffer, Kodi will stop playback till the buffer has been filled again. Depending on your location, the only option may be to limit the bitrate of the stream to play somewhat uninterrupted.

So my suggestion is to try and find the best combination of CDN source and stream protocol manually, and then lock it in in settings.

Catchup CDN source on "Any" means that the add-on will pick randomly one of the streams available. It does not mean it can switch between streams on the fly.

No, if you switch "Play streams automatically using these settings" off, then please keep "Catchup CDN source" on "Any". However, you may try HLS and DASH as stream protocols. This will give you different streams to select manually for each programme. Try which one works well. I know this is a bit tedious, but it is currently the only way in some locations.

While HLS may be better in terms of buffer control in Kodi, in my experience these streams are even slower. It seems to me that the Beeb are limiting HLS more and more because it is hardly ever used any more. Most devices use DASH by now.

(2019-04-15, 07:29)CaptainT Wrote: [ -> ]

(2019-04-14, 21:45)normadize Wrote: [ -> ]Thanks, I'll try those. But, regardless of the settings, are you saying that playing via your addon will always be more error prone compared to playing directly via browser?

"Catchup CDN source" was already on "Any".

If I switch off "Play streams automatically using these settings" then I still need to choose an option for "Stream protocol" and "Catchup CDN source". Currently those are "HLS" and "Any". Does "Any" mean it will try and find the best CDN for my location or do you suggest to take each of those in turn as well to find if there is one that works?

I would have thought HLS is better buffering and bandwidth wise. I'll try DASH as well. 

The underlying issue is, that Kodi is currently unable to switch streams (or even bitrates in the same stream) on the fly. This is what iPlayer in a web browser does. If there is a temporary congestion in your area, it will simply reduce the bitrate (and quality) of the stream temporarily. But it will continue to play. Kodi is unable to do that according to my knowledge. So if the selected stream runs low on buffer, Kodi will stop playback till the buffer has been filled again. Depending on your location, the only option may be to limit the bitrate of the stream to play somewhat uninterrupted.

So my suggestion is to try and find the best combination of CDN source and stream protocol manually, and then lock it in in settings.

Catchup CDN source on "Any" means that the add-on will pick randomly one of the streams available. It does not mean it can switch between streams on the fly.

No, if you switch "Play streams automatically using these settings" off, then please keep "Catchup CDN source" on "Any". However, you may try HLS and DASH as stream protocols. This will give you different streams to select manually for each programme. Try which one works well. I know this is a bit tedious, but it is currently the only way in some locations.

While HLS may be better in terms of buffer control in Kodi, in my experience these streams are even slower. It seems to me that the Beeb are limiting HLS more and more because it is hardly ever used any more. Most devices use DASH by now. 

I tried it and now I see what you meant. After switchigg autoplay off, then when hitting play I'm presented with a list of all stream CDNs and bitrates (about 20 of them in total). This gives control ... and it helped greatly already! I chose 5.5 Mbps on a specific CDN and could watch uninterrupted for almost 1h, which never happened before.

Great stuff! Do you have a donation address so I can support you guys?

(2019-04-15, 13:53)normadize Wrote: [ -> ]Great stuff! Do you have a donation address so I can support you guys?

Glad to be of help!

There is no donation address for this add-on. If you would like to donate, simply use the general Kodi donation address: https://kodi.tv/contribute/donate

Would any of the donation reach you? I've already donated to Kodi several times

(2019-04-15, 16:20)normadize Wrote: [ -> ]Would any of the donation reach you? I've already donated to Kodi several times

No, it would not. But it doesn't need to. I don't do this for money.

Obviously you don't do it for money. Doesn't mean you don't deserve some for it.

Many thanks for your time and efforts!