Kodi Krypton Just Too Unreliable on RPi
#16
(2017-05-31, 12:44)jmooremcc Wrote: Out of curiosity, have you had success viewing weak signal TV channels using Krypton running on OSMC? So far two distros have shown the same problems which leads me to think that it may not be a distro issue but a Kodi issue. I'll give OSMC a try and let you know what happens.

I haven't noticed any difference in the playback of weak TV signals with Krypton. Generally, if I can stand watching a recording or live channel with pixelation, drop-outs and the like Kodi will play it for me.

My setup is mobile though, so I do go to some lengths to optimize my over-the-air antennas. If I'm near a major metro area in flat country, just about any antenna will do. In more rural or mountainous areas, I'll often deploy separate antennas for VHF and UHF, both with pre-amps mounted within a few feet of the antenna. I also use a distribution amplifier to reduce/eliminate splitter loss since my OTA signals feed 2 HDHRs and 2 TVs directly. Since each HDHomeRun counts as two tuners, even this basic setup is a 6-way signal split -- hence the need for a distribution amp. All connections are made with RG-6 coax. If you're interested in specifics of the antennas and amps I use let me know and I'll get you details. I don't use anything massive, because it needs to be portable and has to break down for storage.

Quote:Another issue with Krypton has to do with time shifting. NextPVR time shifting is a hit or miss proposition under Krypton compared to Jarvis. Frequently going back in time can cause the system to freeze and show a "Tuner Not Available" message under Krypton.

No problems here with skipping back during playback, though I don't have to do a lot of that since Comskip does a pretty darn good job of automating the commercial skipping process. I've never seen a "Tuner Not Available" message in the middle of watching something -- could this be an issue with your backend or your particular PVR addon? Any clues in the log when this happens? I use MediaPortal v1 as my backend and at times use the MediaPortal client on my Windows machines. With the Titan skin available on both, they look and operate about the same.

Quote:Finally, Jarvis is so much faster starting up compared to Krypton. Specifically Krypton is really slow importing the program guide, recordings and channel information from the backend server compared to Jarvis.

These sound like the type of issues that had me move from LibreELEC to OSMC. I was seeing very slow importing of just about everything. Scanning my library was like watching paint dry. Deleting my databases and starting fresh made no difference. Anything that had to access my network was slow. A quick OSMC build and I was loving my RPi again! BTW, my "Living Room" HTPC setup is Windows based so I'm always able to compare what's happening with Kodi on the RPi with Kodi on Windows. Kodi Krypton 17.1 to 17.3 are exceptionally solid and are well worth the effort to deploy.

Quote:I like many things about Krypton, especially Estuary. However, the bottom line is reliability and Krypton just isn't ready for prime time when it comes to reliability!

I had the same experience moving from OpenELEC (Jarvis) to LibreELEC (Krypton) on the RaspberryPi. However, I believe it's the distro that's causing your issues since OSMC (Krypton) and Kodi 17.3 (Windows) are running great for me in heavy daily use. Let me know how it goes.
Reply
#17
(2017-05-31, 02:34)nickr Wrote: A debug log (wiki) showing the issue would be a great starting point. And I don't know the code at all, not everyone on the team is a developer Smile

If you are a developer with skills in the area, you may well get on the team yourself. New devs are always welcome.
I wrote a Kodi Log Comparison Utility in Python to analyze my Jarvis and Krypton logs. It appears that the EPG scraper (TVDB) may be the source of the slow boot problem. Take a look at the following log: https://pastebin.com/qrhfCZg9

My log analyzer reports results in relative time and matches the events found in each log. My log also shows the time differential between Jarvis and Krypton for each log entry. This analysis has confirmed my original observation that Krypton takes 2:18 longer to process the same number of channels during boot up.

The log in my paste bin is showing only the "EPG - UpdateFromScraper" event. I suspect that somehow the TVDB addon may be the source of the problem since it is apparently used to update the EPG for each channel. If this addon is the reason for the longer Krypton boot, the next question has to be what has changed to cause this problem.

Please let me know your thoughts on the issue after you review the pastebin log.



Sent from my GT-P3113
Reply
#18
Try reducing the amount of time that the EPG scrapes ahead and see if it improves boot time.
Reply
#19
(2017-06-30, 22:42)ActionA Wrote: Try reducing the amount of time that the EPG scrapes ahead and see if it improves boot time.
How?

Sent from my GT-P3113
Reply

Logout Mark Read Team Forum Stats Members Help
Kodi Krypton Just Too Unreliable on RPi0