Beiträge von Nirvana777
-
-
Describe what you did (e.g. what did you do for settings), even better provide a debug [definition='1','0']log[/definition]. Android armv7a I cannot test myself.
-
Version 20.7.6 tries to fix the slow zapping resulting from Kodi not picking inputstream.adaptive
I could only test on Coreelec which is linux, not android... Linux armv7a works.
Tested with Coreelec 21 though and inputstream.ffmpegdirect not installed. Not sure of that makes a difference.
Version for Linux arm and android arm in 1st post and on github.
-
Regarding armv7a: everybody with a bit more time can also build their own android armv7a cross-compile environment.
Guide is here: https://github.com/xbmc/xbmc/blob…ADME.Android.md
-
Glad to hear.
This addon implements the PVR API of Kodi. On this API Kodi does not support VOD.
VOD would mean different API = different addon = different programming language.
-
Hi, when I try to install version v20.7.4 of addon, after installation Kodi (20.2) crush.
Correct. I've forgot the web startup with empty credentials. Please try the new version in 1st post.
-
- Version 20.7.4 in github & 1st post for linux x86 and android aarch64
- Extend EPG information with live flag, season/episode numbers, age rating
- Thx to the efforts of kalehrl we have found out that actually not the addon code is bad but my cross-compilation environment for armv7a is broken
- If someone would be so kind and provide a compiled version for armv7a of 20.7.4 that would be great. Maybe stoynoff you can help here with your Orange Pi 😉
- lekovic and all, you may delete your logs - thank you for providing them. That has helped to find the root cause
-
I see people still complaining about the zapping times. As we know the reason ffmpeg...
It would be cool if they could find out what these people have in common. Are they all using armv7a version?
I only test linux/x86 and android/aarch64 which work both for me.
Please tell them that the zapping can only change if we find the root cause. Reporting is good but not sufficient. At least some infos would be helpful. Best is logs of course...
-
Version 20.7.3 in the 1st post.
I didn't really find anything why it wouldn't use inputstream.adaptive but I improved debugging. kalehrl Therefor a new debug [definition='1','0']log[/definition] would make sense.
-
Intermediate analysis:
Zapping is slower because the internal player of Kodi is used instead of inputstream.adaptive - in the presented logs independently if VPN is used or not.
No clue so far why this happens. The Stream URL is constructed the same way and the streaming property paramters are also identical. Plus on my side it works correctly. However the bug is reproducable whenever kalehrl switches versions.
If someone knows why it happens or also suffers from Kodi using the internal player please report here.
-
No, but honestly I've never downgraded to explore what happens.
-
Can you do me a favour and do 3 debug logs:
1) 20.6.1 without VPN
2) 20.7.2 without VPN
3) 20.7.2 with VPN
All shortly playing an identical channel.
I guess somehow it selects a different streaming server now.
You can also send logs via PM. Thanks for finding out that it is different with VPN. That really helps to find the difference.
-
From your [definition='1','0']log[/definition] I've noticed that you were on version 20.6.1. That's a much bigger jump to 20.7.2 - not just the EPG issue.
And it makes it harder to tracedown...
The biggest change was that you could emulate AndroidTV instead of a web browser. Are you using Android TV in the settings? Maybe a switch back to web would help as this was the only option in 20.6.1.
Additionally two test versions of 20.7.3 for testing.
-
That's what I meant with someone just having a theory (but no clue of the matter)
I didn't change anything in the zapping. Just the EPG. And I cannot confirm. Same zapping times as before on my side.
-
This piece of information was given to me in a private message on another forum by a reputable member who knows a lot about this stuff.
I've pushed a new version to the github. With that version you can switch to inputstream.ffmpegdirect in the settings. (Remember to restart for it to become effective)
However just using it is not enough. It displays correctly the length of the event and happily plays it, but fast forward or skipping leads into a crash.
So I guess something is missing.
Can you please ask the reputable member for the concrete KODIPROPS settings of ffmpegdirect? Documentation is here but it is not clear to me how to construct a
catchup_url_format_string for example. Problem is that the time is not given in the plain url and in the hls segments there is just offset and pointeroffset. How are they translated for a catchup url?
-
New version in 1st post and on github. Should fix the EPG issue.
-
Ok, it's a bug. My error. The date has grown into an integer overflow. Easy to fix. Stay tuned.
-
It could also always happen that the API has changed on the backend. Personally I cannot test right now since I am abroad.
A debug [definition='1','0']log[/definition] could help to clarify.
-
..I will give it a try as soon as I find some time. It might be some days or weeks.
-
That is an interesting piece of information. I wonder if it is just a theory or if someone tried out practically. If so is it a private project?
Anyway using inputstream.ffmpegdirect would not be a too big of a change I assume.
Regarding the compilation: that is too few information. I don't know what is wrong there.
