ChanServ changed the topic of #libreelec to: [ LibreELEC Support Channel ~ current release: (Leia) 9.2.6 ~ No discussion/support for piracy addons/services ~ Log: https://freenode.irclog.whitequark.org/libreelec ]
psymin has quit [Quit: Leaving]
held has quit []
held has joined #libreelec
Fenster has joined #libreelec
parabyte has quit [Quit: Leaving]
Tobbi has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nikolay_ has quit [Ping timeout: 264 seconds]
hijacker has joined #libreelec
turm01l has quit [Ping timeout: 265 seconds]
turm01l has joined #libreelec
tsal has quit [Ping timeout: 264 seconds]
tsal has joined #libreelec
fraggle_boate_ has quit [Remote host closed the connection]
fraggle_boate_ has joined #libreelec
fraggle_laptop has quit [Ping timeout: 265 seconds]
fraggle_boate_ has quit [Ping timeout: 265 seconds]
fraggle_boate has joined #libreelec
fraggle_laptop has joined #libreelec
Israphel has quit [Ping timeout: 240 seconds]
Israphel has joined #libreelec
buzzmarshall has quit [Remote host closed the connection]
kriger has quit [Read error: Connection timed out]
IPFreely has quit [Quit: I quit!]
lolek has joined #libreelec
_xor has quit [Ping timeout: 260 seconds]
RaphGro has joined #libreelec
Tobbi has joined #libreelec
Fenster has quit [Read error: Connection reset by peer]
Fenster has joined #libreelec
_xor has joined #libreelec
ndufresne2 has joined #libreelec
ndufresne has quit [Read error: Connection reset by peer]
ndufresne2 is now known as ndufresne
damex has quit [Ping timeout: 246 seconds]
TomTom has joined #libreelec
damex has joined #libreelec
damex has quit [Ping timeout: 240 seconds]
MichaelOF has joined #libreelec
ndufresne2 has joined #libreelec
ndufresne has quit [Ping timeout: 272 seconds]
scj643 has quit [Ping timeout: 272 seconds]
ndufresne2 is now known as ndufresne
scj643 has joined #libreelec
TheSilentLink has quit [Quit: Good Bye! My bouncer has probably crashed or lost connection to the internet...]
TheSilentLink has joined #libreelec
andy-burns has joined #libreelec
<sopparus>
vpeter: are you absolutly sure it couldnt be gnutls vs openssl thing?
<sopparus>
:D
andy-burns has quit [Ping timeout: 256 seconds]
<sopparus>
hm network-tools seems missing from repository again
<vpeter>
If connection works then tls is fine. Whatever it is used (gnutls or openssl). You do have a problem with "unstable" connections.
<sopparus>
ok, i will dedicate this afternoon to reproduce
<sopparus>
do you have a zip of that netwoork-tools?
<chewitt>
twanny796 look at /storage/.kodi/userdata/sources.xml .. edit to add/remove/change source folders then reboot or restart Kodi to effect the change
<chewitt>
sopparus I switched the RPi4 to nightlies (self-built, but same) and ran into my usual issue with nothing downloading from the Kodi repo
<chewitt>
rebuilt with curl build against openssl not gnutls .. and all is good again
<chewitt>
vpeter Cubox-i arrived from SR .. how do I get a UART output? .. do I have to pop the case open?
fraggle_boate has quit [Ping timeout: 240 seconds]
<chewitt>
(being lazy.. and their support site is meh)
fraggle_laptop has quit [Ping timeout: 256 seconds]
fraggle_boate has joined #libreelec
fraggle_laptop has joined #libreelec
<sopparus>
Its not there
<sopparus>
Cant see it
IPFreely has joined #libreelec
IPFreely has quit [Remote host closed the connection]
IPFreely has joined #libreelec
andy-burns1 has joined #libreelec
andy-burns has quit [Ping timeout: 256 seconds]
andy-burns1 is now known as andy-burns
<vpeter>
chewitt: device has micro usb connector. Connect it with usb cable to computer and open serial terminal on new usb device.
ghostcube has joined #libreelec
<vpeter>
curl is already build with openssl (gnutls is disabled). So where is the difference?
<sopparus>
its openssl in ubuntu wsipnex said
<sopparus>
just to rule out any difference
<sopparus>
anyway, any ideas on how to get tcpdump now?:)
Fenster has quit [Read error: Connection reset by peer]
Fenster has joined #libreelec
<sopparus>
ok i built it and installed the zipfile
<sopparus>
which seemed to work, but there is no tcpdump program like it was last time
<sopparus>
ok found binary, and it works
Fenster has quit [Ping timeout: 240 seconds]
<sopparus>
vpeter: is it all network traffic on that interface I/you need? execept ssh
<sopparus>
while it happens ofcourse
pragmaticenigma has joined #libreelec
MichaelOF has quit [Quit: Konversation terminated!]
LjL has quit [Quit: Scappò via con la paura di arrugginire. Il giornale di ieri lo dà morto arrugginito. I becchini ne raccolgono spesso fra la gente che si lascia piovere addosso.]
LjL has joined #libreelec
<chewitt>
can't seem to get UART output from the Cubox, but it booted into LE first time
<chewitt>
some messages on-screen
<chewitt>
and it doesn't appear to like the 10" 1080p LCD that I use for testing
<sopparus>
my sister gets this too, I think its becouse so few has the media source over wan, or forums would be flooded :)
buzzmarshall has joined #libreelec
Fenster has joined #libreelec
kriger has quit [Read error: Connection timed out]
<pragmaticenigma>
If you're trying to play a media file hosted on the Internet, that isn't a fault of Kodi or LibreElec. A single dropped packet would be enough for that to happen. If you look at a website while you use their streaming service, and enable the developer mode, you'd see that the video being streamed is broken into little chunks. This helps avoid the video ending play back when there are connection issues
<sopparus>
its my own server
<sopparus>
with mkv file, played over webdavs
<sopparus>
I use cache, in this case the buffer was 60 mb. file had low bitrate so kodi had about 25 seconds to reconnect
<sopparus>
it tried, but fails
<sopparus>
if I kill tcp states on my nat server it starts working again
<pragmaticenigma>
you can play around with all those settings, you will still eventually fail.
<sopparus>
i dont get your point
<sopparus>
but ok thanks
<pragmaticenigma>
Let me retry my example. Youtube doesn't try to send a full 500MB file for you to stream. Instead, it is broken into smaller chunks. The player receives a file with a manifest telling it where all the pieces are. It starts to download them sequentially and begin playback with the first chunk. This approach prevent connectivity issues from interupting the stream. Because the chunks are small enough, they can be cpatured
<pragmaticenigma>
quickly. And usually enough chunks are cached locally that playback goes un-interrupted
<sopparus>
Yes, i know that. But indont see why this wouldnt work
<sopparus>
I usually do
<sopparus>
It
<pragmaticenigma>
Because when it's one contiguous file, if anything interupts the download, everything has to basically start from the beginning. The client/player re-requests the file, offering a byte offset to continue the previous download. If the server supports that, it then has to reload the file from disk, and seek the file to the byte offset. In all this time, the player easily will time out waiting for the server to respond and thus
<pragmaticenigma>
assumes it reached the end of the file
<pragmaticenigma>
And if the server doesn't support byte offset requests, it has to start from the very beginning and the client sits there paused until the download reaches the same point it was at in the beginning. Thus re-downloading everything that was already viewed.
<sopparus>
It does, since resume works
<sopparus>
Its nginx, standard stuff
<vpeter>
sopparus has a problem with tcp connection got killed in the middle. But Kodi is not aware of this.
<pragmaticenigma>
sopparus, if you know your stuff... then you'd know there is a lot more to this equation going on. The short of this is, it will never work reliably over the Internet. Your ISP could be terminating the connection for network management, the server could be doing something internally taking priority of the disk or network controller, your own modem could have faulted and dumped all it's packets. There are many more factors here.
<sopparus>
Messured speed with curl is full gigabit, server does nothing else, overkill hardware. I have no modem, a computer as nat device
<sopparus>
It has worked in the past (and still does except this sometimes happens)
<pragmaticenigma>
and that still doesn't account for ISP Network Management and other factors. You are trying to do something on the open internet. Anything is possible there and stuff will happen. Learn to make a real streaming server that uses things like RTMP or WebRTC to handle the streaming and you will see that stuff like this goes away. Take a straight file from a remote server will always have issues. You've been fortunate that it's
<sopparus>
Anyway i get your point but it cant be done
<sopparus>
Does flex work like that?
<pragmaticenigma>
Plex you mean? I've heard of people using it like that. Don't know much else about it
<sopparus>
Yes plex
<sopparus>
Btw this does not happen on ubuntu or linux, its totally reliable there
<vpeter>
pragmaticenigma: I can dl gigabyte and gigabyte of data in one tcp connection. There is no reason to fail. Only in some very rare case.
<sopparus>
Or windows i meant
<pragmaticenigma>
vpeter, if you're talking about a file download... that would be expected... the issue we're talking about is downloading and playing back the file at the same time. If a regular file download stalls for a moment, no big deal. But doing it in a video player, it's going to be less tolerant to long wait periods to resume the connection
<vpeter>
Do you even know what issue sopparus has?
<pragmaticenigma>
sopparus, you're comparing a multithreaded and lots of RAM PC to a Raspberry PI... think about that for a moment
<sopparus>
But does not only happen when pause, anyways it describes the issue
<sopparus>
Also on libreelec this happens on nuc as well, with ram and cores
<pragmaticenigma>
You've been at this over a year... I would have long went in search of a better and more stable option by now. I'm done with this is all I feel like I'm doing is wasting my time going in circles
<sopparus>
Two years probably
<vpeter>
pragmaticenigma: You didn't wrote single useful info :)
<vpeter>
But let me explain his problem if you didn't get it for now:
<vpeter>
Kodi opens TCP connection to server and starts playing content. After some time pause is pressed and tcp connection is idle. Seems fw/nat/whatever in the middle closes tcp connection after some time but Kodi is not aware of this. And it detects the problem way too late.
<vpeter>
One option would be to send keep alive. Forgot if this helped or not.
<sopparus>
it does with pause.
<sopparus>
but the bigger issue is that this happens often after watching an episode, and when you press play on the next one it cant connect and kodi says "missing item, do you want to delete it"?
<sopparus>
its just easier to reproduce with pause
<sopparus>
and curllowspeed 0 does not help with that
<pragmaticenigma>
if all this is, is a remote storage... why not use something like SFTP or NFS and skip the monkey business with a web server
<buzzmarshall>
webdav has always had issues with certain streams as its old and really was never created for streaming purposes in this manner
<buzzmarshall>
seems to work ok for awhile then as software pieces evolve it acts up again
<buzzmarshall>
not that it can't work but its always been problematic with streaming
<sopparus>
as I understand it there is nothing "webdavish" about this, its just normal http(s)
<buzzmarshall>
the only way i have ever seen it truly fixed is to recompile the server sources more specific to your needs
<buzzmarshall>
which isn't worth the headache as theres better methods now
<sopparus>
sftp had horrible performance back in the day
<sopparus>
dont know today
<sopparus>
on openelec
<sopparus>
nfs needs vpn right
<buzzmarshall>
webdavs really is just a http extension created to allow editable shared files
<buzzmarshall>
it was never really created to stream
<buzzmarshall>
tho in general purpose it can be made to work kinda
<sopparus>
so what could replace it then?
<pragmaticenigma>
I don't see anything in WebDAV feature set that would make sense for streaming. No idea why it's recommended or suggested as a solution
<buzzmarshall>
as streammings evolved tho its never really been kept updated
<sopparus>
i dont see this being a webdav problem anyways
<sopparus>
i can reproduce same thing on a popular addon
<buzzmarshall>
you can make it work but you need to recompile the sources outside the normal tree used by most of the available software packages
<vpeter>
You guys really don't understand the main problem here :)
<sopparus>
with normal http
<pragmaticenigma>
aparently neither do you vpeter, or you would have already solved this problem for this person over a year ago
<buzzmarshall>
ya it goes to sleep and then don't remove locks
<buzzmarshall>
those locks lead to timeouts
<buzzmarshall>
part of the problem has always been with its locking mechanism
<buzzmarshall>
it was never designed with streaming in mind
<sopparus>
do you read every other line or what
<sopparus>
vpeter> Kodi opens TCP connection to server and starts playing content. After some time pause is pressed and tcp connection is idle. Seems fw/nat/whatever in the middle closes tcp connection after some time but Kodi is not aware of this. And it detects the problem way too late.
<sopparus>
same happens on http used by biggest media service in sweden
<sopparus>
only happens when behind NAT
PasNox has quit [Quit: Quiting]
PasNox has joined #libreelec
<vpeter>
pragmaticenigma: It is not my issue. And I don't like to debug remotely. I gave much info what to look.
<vpeter>
Anyway, one less issue I will look.
|Jeroen| has joined #libreelec
pragmaticenigma has quit [Quit: Leaving]
gouchi has joined #libreelec
RaphGro has quit [Quit: Please remember your own message. It'll be read as soon as possible.]
lainlives has joined #libreelec
lainlives has quit [Ping timeout: 264 seconds]
kriger has joined #libreelec
kriger has quit [Read error: Connection timed out]
ghostcube has quit [Quit: Verlassend]
IPFreely has joined #libreelec
|Jeroen| has quit [Quit: dada]
lolek has joined #libreelec
gouchi has quit [Remote host closed the connection]
Fenster has quit [Ping timeout: 272 seconds]
andy-burns has quit [Ping timeout: 246 seconds]
Fenster has joined #libreelec
ernstp has quit [Read error: Connection reset by peer]