LiveTV - No channels load after hitting hung channel

[puithove 208]

Recently started using LiveTV with an m3u source. I'm running into an issue where if I tune to a bad (maybe hung?) channel, from then on, I'm not able to tune to any other channel (known good channels included) on any other client.

 

In the attached log when I was trying to reproduce this - I restarted the server to start with a clean log.  I attempted to tune to the known BAD channel twice - and got an expected result.  The provider sent back a 403, and Emby handled it properly - meaning it returned a 500 to the client (I'm snipping out of the log just to show the times - full log attached):

2019-02-22 06:20:50.251 Info HttpClient: Http response 403 from http://185.134.22.15:8080/redacted/redacted/12982 after 220ms. HeadersServer=nginx, Date=Fri, 22 Feb 2019 11:20:50 GMT, Connection=close, Access-Control-Allow-Origin=*

...
2019-02-22 06:20:50.311 Info HttpServer: HTTP Response 500 to 10.69.1.198. Time: 1451ms. http://10.69.1.10:8096/emby/Items/455713/PlaybackInfo?format=json

Then I successfully played a different channel.

 

Then I again tried the known bad channel and it handled it properly:

2019-02-22 06:21:19.535 Info HttpClient: Http response 403 from http://185.134.22.15:8080/redacted/redacted/12982 after 220ms. HeadersServer=nginx, Date=Fri, 22 Feb 2019 11:21:20 GMT, Connection=close, Access-Control-Allow-Origin=*

...
2019-02-22 06:21:19.542 Info HttpServer: HTTP Response 500 to 10.69.1.198. Time: 232ms. http://10.69.1.10:8096/emby/Items/455713/PlaybackInfo?format=json

But then on a later attempt, the provider returns a 200 (after a long 21s wait), and the stream appears to start but then immediately end

2019-02-22 06:26:28.570 Info App: Opening SharedHttpStream Live stream from http://185.134.22.15:8080/redacted/redacted/12982
2019-02-22 06:26:28.570 Info HttpClient: GET http://185.134.22.15:8080/redacted/redacted/12982
2019-02-22 06:26:49.631 Info HttpClient: Http response 200 from http://185.134.22.15:8080/redacted/redacted/12982 after 21061ms. HeadersServer=nginx, Date=Fri, 22 Feb 2019 11:26:49 GMT, Connection=close, Access-Control-Allow-Origin=*
2019-02-22 06:26:49.632 Info App: Beginning SharedHttpStream stream to /tmp-disk/emby/transcoding-temp/5e89cbc0b968479498d89acba1848fd7.ts
2019-02-22 06:26:49.632 Info App: SharedHttpStream is done streaming.
2019-02-22 06:26:49.632 Info App: Deleting temp files /tmp-disk/emby/transcoding-temp/5e89cbc0b968479498d89acba1848fd7.ts

On the client side at this time, the spinner of death runs for a while - I think in this case I probably hit the back button to go back to the guide.  The client ends up reporting that it's unable to play channel.  All further attempts to play known good channel (including on other clients) results with just a hang.  Log file ends with one final attempt at starting a channel and the client in this "hung" state - client/player on the spinner like it's trying to load the channel, but it's not loading.

 

The only way to get working again is to restart the server.  Which reminds me, I need to put in a feature request in the AndroidTV app to have a restart server option buried somewhere

 

It works the same whether the client is set to DirectStream or in this case DirectPlay.

embyserver.txt

Edited February 22, 2019 by puithove

[Luke 37248]

Thanks for reporting. I think this should be resolved for the next release.

[puithove 208]

Great, thanks Luke!

[hshah 19]

@@puithove, are you still experiencing this?  I've recently started playing around with IPTV and noticed the same behaviour today (found this thread when I was searching to see if anyone else had similar issues).

 

@@Luke, was this resolved?

[Luke 37248]

I think this should be resolved for the next release.

[hshah 19]

I think this should be resolved for the next release.

 

Are we talking about main release or the betas?

[Luke 37248]

In this section of the community we only talk about the stable release, so that I was referring to the upcoming 4.1 release.