Streams stutter in live - Kodi (19.0-ALPHA1 (18.9.701) Git:20200608-00f5af0cec). Platform: Android ARM 32-bit

[Gregsr]

When I enable timeshift or catchup in PVR IPTV Simple Client, the streams stutter (caching/playing continuously; I don't use any functions "rewind/pause and fast-forward"). When I disable, it is smooth.

On Win7 64bits, no issue

kodi.log

[phunkyfish]

Interesting. I wonder is it cause it’s a 32bit or something else.

I guess not easy to find out.

[phunkyfish]

If you use timeshift and you rewind after the buffering does it still occur at the same times?

[Gregsr]

When I load a stream, I cannot directly rewind (timeshift seems to be not active). First, I have to pause (at A point) and I wait for a few seconds. Next, I play and, after x seconds, it stutters. Then I rewind until the A point (I cannot rewind before) and, after x+y seconds, it stutters. And etc... (The duration without stutters increases)

https://paste.kodi.tv/topefutera.kodi

[phunkyfish]

Yes, timeshift will only work since the time the stream loads. So you would need to leave it running for example for 2 minutes and note down at which times it stutters.

Then seek back to the start and see does it stutter again on playback at the same times.

It might be to do with how the data is saved on your storage. But the above test should tell us if that’s the issue.

[Gregsr]

"I cannot directly rewind " meaned that timeshift works only after I pause the stream. Finally, after tests, I remarked that timeshift is available (without other actions) after xx seconds of playing.

Test:

1. Start stream
2. Running 60sec (Stutter = 10-15% buffering/2-3sec playing (cyclic))
3. Rewind from 60 sec to start
4. Stutter from 60+x sec (x=11-12 sec)
5. Rewind from 75sec to start
6. Stutter from 75+x sec (x=11-12 sec)
7. Etc

[phunkyfish]

And none of these issues occur on Windows?

[Gregsr]

I redid tests on Windows and the issue occurs sometimes but not each time when I start a stream.
When I rewind, the issue seems to disappear.

[phunkyfish]

And on the arm device once you rewind is playback ok? I.e. no buffering as it’s not playing live?

[phunkyfish]

Could you try something? In userdata/addn_data/timeshift you should see the timeshift files get created as the stream starts. For the ARM device I wonder if the first files don't get written until a certain point, i.e. they are not flushed to disk or something. Could you check when they are being created? They shouldn't be required to be on disk to be able to seek but maybe it's related to why you have to wait 60 seconds.

[Gregsr]

And on the arm device once you rewind is playback ok? I.e. no buffering as it’s not playing live?

No, it is'nt. Playback is smooth a moment but stutter start again (see above the results of the test to have timings)

[phunkyfish]

But in your timings you show 60+x. Does that mean after rewinding to the start it plays ok until 60 seconds? Or that it stutters after 11/12 seconds after rewind?

What’s interesting is that the segment size is approx 12 seconds so may be a read/write issue.

[Gregsr]

1.a At 00:01:00 in live, I rewind to 00:00:00 (note I cannot reach 00:00:00, I can only reach 00:00:11/12, maybe because of the same issue)
1.b Playback is smooth until 00:01:11/12, after this timing, stutter starts again

2.a At 00:01:30 in live, I rewind to 00:00:00
2.b Playback is smooth until 00:01:41/42(=30+11/12), after this timing, stutter starts again

11/12 seems to be a constant value

I will check timeshift files

[phunkyfish]

Strange. So for anything that you have already watched live if you rewind it plays smoothly but for anything once you reach the unwatched part + 1 segment it stutters.

[phunkyfish]

If you watch 5 minutes and rewind to the start does the stuttering start again at 00:05:11/12?

[Gregsr]

Could you try something? In userdata/addn_data/timeshift you should see the timeshift files get created as the stream starts. For the ARM device I wonder if the first files don't get written until a certain point, i.e. they are not flushed to disk or something. Could you check when they are being created? They shouldn't be required to be on disk to be able to seek but maybe it's related to why you have to wait 60 seconds.

Is there an addon to have more information (created date) than with File manager of Kodi? If I return to the Home screen of the box to check timeshift files with an explorer app, Kodi stops the stream and timeshift files are deleted.

[phunkyfish]

I think you will need to install/use ssh. Once you have that you can connect to the box on the command like and look at the filesystem.

[Gregsr]

Could you try something? In userdata/addn_data/timeshift you should see the timeshift files get created as the stream starts. For the ARM device I wonder if the first files don't get written until a certain point, i.e. they are not flushed to disk or something. Could you check when they are being created? They shouldn't be required to be on disk to be able to seek but maybe it's related to why you have to wait 60 seconds.

Here are the list of timeshift files with created date and the log file with a lot of warnings for the buffer.

https://paste.kodi.tv/gixozokuhe.kodi

[Gregsr]

If you watch 5 minutes and rewind to the start does the stuttering start again at 00:05:11/12?

I did 2 type of test (on ARM):
A. I leave the stream runs (with stuttering) and the video freezes totally after 00:03:49, I rewind and it freezes totally after 00:03:40 (it is smooth before). I note that it is not possible to fast-forward after 00:03:40

B. I pause directly the stream, I play after 5 min of pause and stuttering start again after 2min (playback is smooth before)

[phunkyfish]

There should be a new segment file every 12 seconds. For some reason the timings are far more than that for you arm device.

Can you check what the timings for the segment files are on windows for the same stream and compare them?

It must be how the data is flushed to disk. If windows looks correct maybe I can create some testbuilds to try different options for ARM.

[phunkyfish]

Could you also provide the contents of the .idx file in a similar test?

[Gregsr]

For ARM, zip file contains .idx file, log file et timings
ARM.zip

[Gregsr]

For Windows
Windows.zip

[Gregsr]

I notice that the issue is less important when the resolution is low. Stuttering is more widely spaced.
Conversely, the issue is greater when the resolution is high. Stuttering is closer together

[phunkyfish]

Ok, so the log matches the creation timestamps which means the files are being written correctly. But the data appears to be arriving slowly to the inputsream. I.e. it takes nearly a minute for the first 12 seconds of data to arrive on Android.

Is there anyway you can disable using OMX player and see if it's any different?

[Gregsr]

I notice that the issue is less important when the resolution is low. Stuttering is more widely spaced.
Conversely, the issue is greater when the resolution is high. Stuttering is closer together

Ok, so the log matches the creation timestamps which means the files are being written correctly. But the data appears to be arriving slowly to the inputsream. I.e. it takes nearly a minute for the first 12 seconds of data to arrive on Android.

Is there anyway you can disable using OMX player and see if it's any different?

How can I disable OMX player? Is it the hardware acceleration?

[Gregsr]

I think I found. I modified the decoderfilter.xml like this
<name>OMX.amlogic.xxxxxxxx</name> <allowed>false</allowed>
The result is worse

[dagwieers]

@Gregsr This resembles our own experience on ARM with/without OMX Player.
add-ons/plugin.video.viervijfzes#4

Multiple add-ons have reported issues with specific streams (often all streams from a single VOD provider). You can test the streams using any of the following stream validation tools or online players:
https://github.com/add-ons/best-practices/wiki/Streaming-issues

It could help identify specific issues with streams.

Note that it is not because streams have issues, Kodi should not be able to handle those better. That is why it helps if you can verify that other players work flawlessly where Kodi has difficulties.

Update: If you click through referenced issues you will find an easy fix that worked for us, which was to increase the buffer queue, but this was not acceptable for Kodi devs. I don't know if this would work for your specific streams either, it will depend on the specific issue with the stream.

[Gregsr]

@Gregsr This resembles our own experience on ARM with/without OMX Player.
add-ons/plugin.video.viervijfzes#4

Multiple add-ons have reported issues with specific streams (often all streams from a single VOD provider). You can test the streams using any of the following stream validation tools or online players:
https://github.com/add-ons/best-practices/wiki/Streaming-issues

It could help identify specific issues with streams.

Note that it is not because streams have issues, Kodi should not be able to handle those better. That is why it helps if you can verify that other players work flawlessly where Kodi has difficulties.

Update: If you click through referenced issues you will find an easy fix that worked for us, which was to increase the buffer queue, but this was not acceptable for Kodi devs. I don't know if this would work for your specific streams either, it will depend on the specific issue with the stream.

Thank you for sharing your experience.
I will test my streams with your reference.

My experience shows I have no issue when timeshift/catchup is not enabled (then when I don't use ffmeg inputstream) and OMX player is enabled. If OMX is disabled, I have stuttering

[phunkyfish]

The only ARM devices I have are Rbpi’s. Let me try this on both a 3 and a 4. Both will be running LibreElec and not the Android build though so maybe not a comparative test.

[phunkyfish]

What if this is because the ARM32 build of ffmpegdirect is not using HW acceleration like it should be causing the delay.

Or it’s incorrectly configured somehow.

Can you try a test where you only open a stream with ffmpegdirect but don’t use catchup or timeshift?

If you add this line just above one M3U entry it should simply open the stream with ffmpegdirect:
#KODIPROP:inputstream=inputstream.ffmpegdirect
This should in theory open the stream exactly like kodi does. If this doesn't work this is the use case we need to fix.

What ARM chip is used in your device?

[Gregsr]

What if this is because the ARM32 build of ffmpegdirect is not using HW acceleration like it should be causing the delay.

Or it’s incorrectly configured somehow.

Can you try a test where you only open a stream with ffmpegdirect but don’t use catchup or timeshift?

If you add this line just above one M3U entry it should simply open the stream with ffmpegdirect:
#KODIPROP:inputstream=inputstream.ffmpegdirect
This should in theory open the stream exactly like kodi does. If this doesn't work this is the use case we need to fix.

What ARM chip is used in your device?

I will try next week because I am not at home until July.

For the ARM chip:
CPU: Cortex-A53 Quad-core 64bit
GPU: Mali-450

Thank for your help!

[phunkyfish]

If you have a 64bit cpu where do you install the 32 bit android build?

[Gregsr]

What if this is because the ARM32 build of ffmpegdirect is not using HW acceleration like it should be causing the delay.

Or it’s incorrectly configured somehow.

Can you try a test where you only open a stream with ffmpegdirect but don’t use catchup or timeshift?

If you add this line just above one M3U entry it should simply open the stream with ffmpegdirect:
#KODIPROP:inputstream=inputstream.ffmpegdirect
This should in theory open the stream exactly like kodi does. If this doesn't work this is the use case we need to fix.

What ARM chip is used in your device?

I will try next week because I am not at home until July.

For the ARM chip:
CPU: Cortex-A53 Quad-core 64bit
GPU: Mali-450

Thank for your help!

If you have a 64bit cpu where do you install the 32 bit android build?

I tried to install the 64 bit build but it did not work, it was a new installation, not a update. I don't know why.
By default, Google play installed the 32 bit version of Kodi 18.6 previously.

[Gregsr]

What if this is because the ARM32 build of ffmpegdirect is not using HW acceleration like it should be causing the delay.

Or it’s incorrectly configured somehow.

Can you try a test where you only open a stream with ffmpegdirect but don’t use catchup or timeshift?

If you add this line just above one M3U entry it should simply open the stream with ffmpegdirect:
#KODIPROP:inputstream=inputstream.ffmpegdirect
This should in theory open the stream exactly like kodi does. If this doesn't work this is the use case we need to fix.

It doesn't work

[phunkyfish]

Very strange.

[Gregsr]

With the Stb Emu app, there is no problem with pause function or catch-up function. However, I do not know the videoplayer. I wonder if the app is not using ijkplayer but I'm not sure

[Gregsr]

I can try on another device (ARMv7 32 bit) but I cannot find the pvr add-on in the kodi repo. How can I install the add-on?

[phunkyfish]

It should install the same way as your current device. did you install using the android apk?

[Gregsr]

Yes the same nightly.
Moreover, on my "first" android device and on Windows 7, I have not the possibility to update the PVR addon (the directory "PVR clients" in the repo has disappeared...). Currently, it is the 5.2.0 version on both.

[phunkyfish]

If you go to My Addons do you see PVR clients?

You may need a new nightly version but I think the latest version of iptvsimple is 5.2.2

[Gregsr]

On the "second" Android device with the fresh installation, I do not see PVR clients in My Addons.
For sure, it is not the case for the first Android device and Windows 7 where I can see it.

OK, I will use the latest nightly version.
If it does not work, I will install Kodi from the Google Store (v18.7) hoping to have the PVR addon and make an update with the latest nightly version.

Is it possible that the PVR addon has been banned?

[phunkyfish]

You will only see PVR addons in My Addons agreeing installing them. Otherwise you need to install from repository. I don’t use android so not exactly sure how this works on that platform.

Ffmpegdirect will only work with kodi 19. The addons are installed from a remote repo so it’s not possible to ban them.

[Gregsr]

That is the first time I have this problem on my Android devices (Xiaomi Mi box S and Minix X8H-Plus).
I try the both solutions this evening.

I believed that the official Kodi repo could blacklist addons like PVR IPTV simple addon.

[phunkyfish]

Iptvsimple is in the official Kodi repo so it’s not that. When you try and install the addon do you see all the other PVR addons?

[Gregsr]

I don't see any on my Android devices. The directory "PVR clients" in the repo is not present.

On Windows 7, I see this (see printscreen)

[phunkyfish]

That looks like the addons you have installed. There should be a dialog listing all the PVR addons you don’t have installed. Can you see that?

[Gregsr]

No otherwise I would have a V checked mark like this (this is the installed PVR addon on Win7)

[phunkyfish]

Strange. There should be about 20 PVR addons available to install.

[Gregsr]

On win7 64bit, I have made a fresh installation with the latest nightly version and I recover PVR clients in the repo.

I will try this evening with my Android devices.

[Gregsr]

On my both Android devices, I have made a fresh installation with the latest nightly and I could to install the 6.2.2 release of the PVR. Timeshift and catchup work nice and smooth. I would like to test a few days before closing the issue. Ok for you?
I do not know if it is because of the nightly version and/or the PVR release.

Did you modify something to solve this issue?

[phunkyfish]

Nope, I didn’t change anything!

[Gregsr]

I suppose that it was because of the nightly version.
Thanks anyway for your help!

[phunkyfish]

NP

[Gregsr]

We can close.
All is smooth