(2021-03-05, 11:11)phunkyfish Wrote: [ -> ]Up to now you are the first person this happens to randomly.
I think core issue, when server disconnects is random. Kodi reaction is not random.
(2021-03-05, 11:11)phunkyfish Wrote: [ -> ]And just to confirm. When it doesn’t work it hangs and when it does work it correctly splices the streams together?
I have no idea, but I suspect it never works in my case. When server disconnects, deadlock. It's random, because not always server breaks connection. I've never seen playback restarted, always result is Kodi dead. BTW, it's not clear for me why not finished or finished event makes any difference, as server actually does not know anything about that, archive on server is continous and time ranges are determined from epg on client side, unless unfinished event causes different server query
(2021-03-05, 12:35)giaur Wrote: [ -> ] (2021-03-05, 11:11)phunkyfish Wrote: [ -> ]Up to now you are the first person this happens to randomly.
I think core issue, when server disconnects is random. Kodi reaction is not random.
(2021-03-05, 11:11)phunkyfish Wrote: [ -> ]And just to confirm. When it doesn’t work it hangs and when it does work it correctly splices the streams together?
I have no idea, but I suspect it never works in my case. When server disconnects, deadlock. It's random, because not always server breaks connection. I've never seen playback restarted, always result is Kodi dead. BTW, it's not clear for me why not finished or finished event makes any difference, as server actually does not know anything about that, archive on server is continous and time ranges are determined from epg on client side, unless unfinished event causes different server query
@
giaur
This sounds like the same problem I have been experiencing. Kodi crashes once the EOF is reached and the video stream stalls. It occurs in both CoreElec and Windows x64 Kodi. I have tried two suppliers with same result. I have been in discussion with @
phunkyfish regarding this.
@
ceekdp
Are you sure? I did not get crash actually, only deadlock and Kodi not responding. But reason is stream stalled, for sure.
It's actually even worse than crash, because crash causes Kodi auto reastart. Deadlock like this causes device not responding to any input and I need to kill kodi process from ssh or disconnect and connect power supply to reboot device.
I think it's serious issue.
(2021-03-05, 20:53)giaur Wrote: [ -> ]@ceekdp
Are you sure? I did not get crash actually, only deadlock and Kodi not responding. But reason is stream stalled, for sure.
It's actually even worse than crash, because crash causes Kodi auto restart. Deadlock like this causes device not responding to any input and I need to kill kodi process from ssh or disconnect and connect power supply to reboot device.
I think it's serious issue.
@
giaur
Apologies, you are correct. I used the term crash incorrectly. What I experience sounds exactly the same as you: Kodi becomes deadlocked and then does not respond. Power reset or reboot through SSH is then needed.
(2021-03-05, 23:22)ceekdp Wrote: [ -> ] (2021-03-05, 20:53)giaur Wrote: [ -> ]@ceekdp
Are you sure? I did not get crash actually, only deadlock and Kodi not responding. But reason is stream stalled, for sure.
It's actually even worse than crash, because crash causes Kodi auto restart. Deadlock like this causes device not responding to any input and I need to kill kodi process from ssh or disconnect and connect power supply to reboot device.
I think it's serious issue.
@giaur
Apologies, you are correct. I used the term crash incorrectly. What I experience sounds exactly the same as you: Kodi becomes deadlocked and then does not respond. Power reset or reboot through SSH is then needed.
Ok, so I'm not alone. I hope this issue will be eventually fixed.
What we need to figure out is if this is new behaviour, i.e. it worked with an older version and is broken now or if it’s just a new stream type that the continue terminating stream feature does not work with.
Hopefully someone who had this working before will chime in and let us know if it still works.
I suspect it never worked and reason is somewhere else, maybe stream type or some other unknown factors.
In my case backend sever is Flussonic with hls stream type, archive format is standard Flussonic archive.
@
phunkyfish
As issue is really serious, can you consider to add switch to enable/disable resume stream functionality? So playback will just stop, but device won't be unresponsible, which is confusing.
It may be even somewhere in advancedvsettings if you don't want to expose it to gui. And add it as rescue option if resume attempts causes really bad behavior.
BTW I don't know if it helps, by I am always able to resume from paused playback, but I think server does not break connection in this case.
Very strange. Terminating catchup should not be used for flussonic at all as flussonic streams should not end.
Can you pm me (or gitter.im me) an example M3U entry @
giaur?
Sorry, I can't provide any real playlist entry as it's confidential. But that's how playlist is constructed:
Code:
#EXTINF:0 tvg-id="Channel name" tvg-name="Channel name" tvg-logo="http://host/logo.png" timeshift="5" catchup="default" catchup-source="http://ip/id/mono-{utc}-{lutc}.m3u8?token=token" group-title="Group name" ,Channel name
http://ip/id/video.m3u8?token=token
I guess we can assume server issues and that's why catchup stops. But still, deadlock at Kodi side needs to be considered as a bug in my opinion. Unfortunately, I have no idea how to let you to reproduce it to perform some debug without sharing real stream link, which I can't do.
Maybe stream dump could help?
(2021-03-06, 12:57)giaur Wrote: [ -> ]Sorry, I can't provide any real playlist entry as it's confidential. But that's how playlist is constructed:
Code:
#EXTINF:0 tvg-id="Channel name" tvg-name="Channel name" tvg-logo="http://host/logo.png" timeshift="5" catchup="default" catchup-source="http://ip/id/mono-{utc}-{lutc}.m3u8?token=token" group-title="Group name" ,Channel name
http://ip/id/video.m3u8?token=token
I guess we can assume server issues and that's why catchup stops. But still, deadlock at Kodi side needs to be considered as a bug in my opinion. Unfortunately, I have no idea how to let you to reproduce it to perform some debug without sharing real stream link, which I can't do.
Maybe stream dump could help?
This is wrong. The add-on supports flussonic natively. In fact if you use the native support it will also play continuously. Please try that first.
(2021-03-06, 13:42)phunkyfish Wrote: [ -> ] (2021-03-06, 12:57)giaur Wrote: [ -> ]Sorry, I can't provide any real playlist entry as it's confidential. But that's how playlist is constructed:
Code:
#EXTINF:0 tvg-id="Channel name" tvg-name="Channel name" tvg-logo="http://host/logo.png" timeshift="5" catchup="default" catchup-source="http://ip/id/mono-{utc}-{lutc}.m3u8?token=token" group-title="Group name" ,Channel name
http://ip/id/video.m3u8?token=token
I guess we can assume server issues and that's why catchup stops. But still, deadlock at Kodi side needs to be considered as a bug in my opinion. Unfortunately, I have no idea how to let you to reproduce it to perform some debug without sharing real stream link, which I can't do.
Maybe stream dump could help?
This is wrong. The add-on supports flussonic natively. In fact if you use the native support it will also play continuously. Please try that first.
That's how provider set playlist. Do you mean to set Flussonic as catchup type? Do I need to edit playlist also to remove catchup source? Or with catchup type set to Flussonic, catchup source tags will be ignored?
(2021-03-06, 13:50)giaur Wrote: [ -> ] (2021-03-06, 13:42)phunkyfish Wrote: [ -> ] (2021-03-06, 12:57)giaur Wrote: [ -> ]Sorry, I can't provide any real playlist entry as it's confidential. But that's how playlist is constructed:
Code:
#EXTINF:0 tvg-id="Channel name" tvg-name="Channel name" tvg-logo="http://host/logo.png" timeshift="5" catchup="default" catchup-source="http://ip/id/mono-{utc}-{lutc}.m3u8?token=token" group-title="Group name" ,Channel name
http://ip/id/video.m3u8?token=token
I guess we can assume server issues and that's why catchup stops. But still, deadlock at Kodi side needs to be considered as a bug in my opinion. Unfortunately, I have no idea how to let you to reproduce it to perform some debug without sharing real stream link, which I can't do.
Maybe stream dump could help?
This is wrong. The add-on supports flussonic natively. In fact if you use the native support it will also play continuously. Please try that first.
That's how provider set playlist. Do you mean to set Flussonic as catchup type? Do I need to edit playlist also to remove catchup source? Or with catchup type set to Flussonic, catchup source tags will be ignored?
There is an example in the readme for pvr.iptvsimple on GitHub. Example channel G.
https://github.com/kodi-pvr/pvr.iptvsimple
So you mean:
#EXTINF:-1 catchup="fs",Channel G
http://list.tv:8888/325/mono.m3u8?token=secret
But I don't want to edit playlist, I can set Flussonic for all channels in addon settings gui, will I get the same result? Or, wrong catchup source from m3u will be still used?
(I want to avoid playlist edit, because it's from url and it changes from time to time, when new channels added, etc)
(2021-03-06, 14:14)giaur Wrote: [ -> ]So you mean:
#EXTINF:-1 catchup="fs",Channel G
http://list.tv:8888/325/mono.m3u8?token=secret
But I don't want to edit playlist, I can set Flussonic for all channels in addon settings gui, will I get the same result? Or, wrong catchup source from m3u will be still used?
(I want to avoid playlist edit, because it's from url and it changes from time to time, when new channels added, etc)
Try doing a single entry in an M3U on its own and text if it works correctly first.
You need to use the format similar to channel G for it to work.