My first problem just appeared. : to install Kryton i have to modify “/etc/apt/sources.list” but this isn’t writable by osmc user. only root has write permission. but “sudo passwd root” asking me to change root password , and not elevates my connection to the root level.
So how to add “deb Index of /osmc/osmc/download/dev/gmc ./” line to sources.list ?
sudo nano /etc/apt/sources.list
Suggest to take a look at the FAQ
@fzinken got a better suggestion
sudo echo "deb http://download.osmc.tv/dev/gmc ./" > /etc/apt/sources.list.d/gmc.list
better for a newbie then he only need to delete that file to remove the repo
BTW I suggest not to use the GMC nightlies but the Beta version I have linked earlier
@emarosvari i can agree on that the nightly has a tendancy to break and if you have no skills with debugging and getting to the root cause then you are only gonna get frusterated.
sudo echo will not work if you direct the output. Consider piping to sudo tee -a
I have installed the new version Beta6. The problem is the same. WIth IPTV Simple Client you can’t play the stream. With DVBLink connectin to DVBLink Server where the list is hosted you can play.
I got the feeling that if there is any problem then it will be in IPTV Simple Client as once you try to play a stream (and nothing happens) the last core of the CPU goes nearly to 100% and keeps there for 2-3 minutes.
Okay, thanks for testing that. I am surprised it doesn’t work with Krypton.
Is this only one / a few streams that are problematic are all of them giving you problems?
<cache>
<memorysize>0</memorysize> <!-- number of bytes used for buffering streams in memory
When set to 0 the cache will be written to disk instead of RAM -->
<buffermode>0</buffermode> <!-- Choose what to buffer:
0) Buffer all internet filesystems (like "2" but additionally also ftp, webdav, etc.) (default)
1) Buffer all filesystems (including local)
2) Only buffer true internet filesystems (streams) (http, etc.)
3) No buffer -->
<readfactor>4.0</readfactor> <!-- this factor determines the max readrate in terms of readbufferfactor * avg bitrate of a video file. This can help on bad connections to keep the cache filled. It will also greatly speed up buffering. Default value 4.0. -->
</cache>
<pvr>
<timecorrection>0</timecorrection> <!-- Correct all times (epg tags, timer tags, recording tags) by this amount of minutes. -->
<infotoggleinterval>3000</infotoggleinterval> <!-- If there is more than one pvr gui info item available (e.g. multiple recordings active at the same time), use this toggle delay in milliseconds. -->
<minvideocachelevel>5</minvideocachelevel> <!-- Cache up to this level in the video buffer buffer before resuming playback if the buffers run dry. -->
<minaudiocachelevel>10</minaudiocachelevel> <!-- Cache up to this level in the audio buffer before resuming playback if the buffers run dry. -->
<cacheindvdplayer>true</cacheindvdplayer> <!-- Cache PVR stream in DVDPlayer. -->
<channeliconsautoscan>true</channeliconsautoscan> <!-- Automatically scan user defined folder for channel icons when loading internal channel groups. -->
<autoscaniconsuserset>false</autoscaniconsuserset> <!-- Mark channel icons populated by auto scan as "user set". -->
<numericchannelswitchtimeout>1000</numericchannelswitchtimeout> <!-- Time in ms before the numeric dialog auto closes when confirmchannelswitch is disabled. -->
<lingertime>60</lingertime> <!-- Limits how far "back" the PVR guide goes from the current time. Time given in minutes. -->
</pvr>
http://kodi.wiki/view/advancedsettings.xml#cache
http://kodi.wiki/view/advancedsettings.xml#pvr
might be worth to mess around with see if there is improvments, btw are these options available to set in myosmc ? @sam_nazarko
This is an issue only with this provider. None of the streams are playable whit IPTV Simple client.
If i give a different source for IPTV simple client then it works well.
When I use my DBVLink with rpi, then the same Rapid IPTV source works perfectly. I have checked my network traffic, and my Rpi is streaming video. It’s not like my NAS box reencoding and then Rpi plays it. So in both case the source is the same. But what isn’t work with IPTV Simple Client works with DVBLink. And the odd is that there is no error on the screen.
Not sure if I have the same issue, but I do have a problem playing Rapid IPTV streams on my Raspberry pi 3 osmc system. I have the november release with kodi 16.1. The streams do not open and the log gives the error:
ERROR: CCurlFile::FillBuffer - Failed: HTTP returned error 401
It is not an access issue though, because I can open the file fine with wget(on the pi) and VLC on my laptop.
Now I even installed kodi 16.1 on my laptop (ubuntu 16.04) and there it also plays fine. Therefore It seems to be and issue with the armhf build. I’m baffled.
For reference I also upgraded osmc to kod 17 beta 5 and the laptop to kodi 18 nightly (couldn’t find a 17 build there) On osmc it still didn’t work. On the laptop it worked fine…
In all I haven’t been able to reproduce the problem on any kodi version on the laptop and I haven’t been able to get it to work at all on any version on the raspberry pi.
Any advice or idea is appreciate.
Bert
Sorry, but troubleshooting pirated TV streams (regardless of whether you paid some pirate for them or not) is outside of the scope of this forum and against our forum TOS.
Im not interested to go into the morrality or legallity.
All I know is that im paying two tv subscriptions now on order not to have to use a crappy settup box of my tv provider. And Im just this close to have the channels working on osmc and a perfect settup.
Im interested in the technical side though. Apperently there is a difference between x64 and armhf in how streams get opened. On the laptop it works like a charm. On the rpi it blocks with error 401. Does anyone have an idea where the difference can lie?
Bert
We’re not interested in providing support for your lack morality. Good luck. Try asking Kodi what the problem is.
You need to contact the company you are paying about this, because we don’t know anything about this service. We ship the latest RTMP libraries with patches, but there’s not much we can do at our end to resolve this. They should be a lot more knowledgeable, and I’d be surprised if they didn’t have a test OSMC setup to work with.