Jump to content

Unstable IPTV - HTTP error 404 Not Found


Thuzad

Recommended Posts

Thuzad

Hey,

 

I used IPTV with m3u file, but the server is'nt stable and the connection drop.

When the connection is dropped by the server, the player is close.

 

Is possible to retry infinity and don't close the player ?

 

Part of log when the player is close:

2018-06-28 13:47:30.343 Info HttpServer: HTTP POST http://streaming.home.personnal.xyz:8096/emby/Sessions/Playing/Progress. UserAgent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
2018-06-28 13:47:30.358 Info HttpServer: HTTP Response 204 to 194.79.152.18. Time: 15ms. http://streaming.home.personnal.xyz:8096/emby/Sessions/Playing/Progress 
2018-06-28 13:47:31.973 Info HttpServer: HTTP POST http://streaming.home.personnal.xyz:8096/emby/Sessions/Playing/Progress. UserAgent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
2018-06-28 13:47:31.974 Info PlaybackReporting - EventMonitorEntryPoint: PlaybackTracker : Adding Paused Event : 6/28/18 1:47:31 PM
2018-06-28 13:47:31.990 Info HttpServer: HTTP Response 204 to 194.79.152.18. Time: 18ms. http://streaming.home.personnal.xyz:8096/emby/Sessions/Playing/Progress 
2018-06-28 13:47:31.999 Info HttpServer: HTTP POST http://streaming.home.personnal.xyz:8096/emby/Sessions/Playing/Stopped. UserAgent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
2018-06-28 13:47:32.000 Info App: Deleting partial stream file(s) /var/lib/emby/transcoding-temp/a317c15f8d451ccebd214c55ba5dd856.m3u8
2018-06-28 13:47:32.000 Info SessionManager: Playback stopped reported by app Emby Mobile 3.4.1.0 playing FR:  Sport 1 HD. Stopped at 22200 ms
2018-06-28 13:47:32.000 Info MediaSourceManager: Closing live stream 09efa0d56b934a82adec00a87b837fb0_ea308dcb42ce458896305314c7ccf3e4_8b17808bc7b1755ac4018ac51641782b with provider LiveTvMediaSourceProvider
2018-06-28 13:47:32.000 Info App: Closing live stream from Emby, stream Id: ea308dcb42ce458896305314c7ccf3e4_8b17808bc7b1755ac4018ac51641782b
2018-06-28 13:47:32.000 Info App: Live stream ea308dcb42ce458896305314c7ccf3e4_8b17808bc7b1755ac4018ac51641782b consumer count is now 0
2018-06-28 13:47:32.000 Info App: Closing live stream ea308dcb42ce458896305314c7ccf3e4_8b17808bc7b1755ac4018ac51641782b
2018-06-28 13:47:32.001 Info App: Closing LiveStream
2018-06-28 13:47:32.001 Info App: Live stream ea308dcb42ce458896305314c7ccf3e4_8b17808bc7b1755ac4018ac51641782b closed successfully
2018-06-28 13:47:32.001 Info HttpServer: HTTP Response 204 to 194.79.152.18. Time: 3ms. http://streaming.home.personnal.xyz:8096/emby/Sessions/Playing/Stopped 
2018-06-28 13:47:32.001 Info PlaybackReporting - EventMonitorEntryPoint: Playback stop tracker found, processing stop : ab58a1712e42dbec47fb88a6b0f75d2e291dff24-4bb14b9730e0495a9658de133c2425bd-82fe31fd077d3216b33a10cdfd3e0d01
2018-06-28 13:47:32.001 Info PlaybackReporting - EventMonitorEntryPoint: PlaybackTracker : Adding Stop Event : 6/28/18 1:47:32 PM
2018-06-28 13:47:32.001 Info PlaybackReporting - EventMonitorEntryPoint: Saving playback tracking activity in DB
Link to comment
Share on other sites

ddurdle

I have tested with two different IPTV providers, one that always seems to provide reliable streams and another where at any second there could be 404 or 403 that go away relatively quickly, but not quick enough before the stream drops.  

 

It is particularly painful on recordings since they'll stop recording.  I came up with a wrapper that handles this well for recordings (been testing for a few months).  The logic doesn't work well for watching Live TV yet.

Link to comment
Share on other sites

@@Waldonnis i added you to the PM with his log files. Any thoughts on this?

[http @ 0x24960c0] Stream ends prematurely at 10730316, should be 18446744073709551615
Error while filtering: Function not implemented

It just looks like bad data in the source stream.

Link to comment
Share on other sites

@@Floflobel, while we wait for him to respond, here's one thing you can try. i notice that in the log it is stream copying the original video. try dropping the quality setting in the video player low enough so that it forces a full video transcode. If it's an issue of bad timestamps, then i wonder if a full transcode will help correct that. Thanks.

Link to comment
Share on other sites

Waldonnis

Could be a timestamp issue or the stream may be "disconnecting" periodically due to an EOF condition, although I'd suspect the latter.  I've seen similar before when the provider is serving a stream faster than it's being written out or the client is running into an EOF condition while the server is still appending to the file.

 

This looks very similar to a previous thread, actually.  Here's a link to my post about it that talks about reconnect options that could help here as well.

Link to comment
Share on other sites

Waldonnis

In conjunction, since I believe stream_loop just forces rereads of the manifest/playlist since that's the "input" (pretty sure that's how it works; I'd have to re-check the code but it makes sense).  ffmpeg seems to be disconnecting because it's hitting an EOF in the stream file itself and, although it knows there should be more, it defaults to not trying to reconnect when it hits that condition.

 

Should be easy to test this with ffplay on the stream, since it should cough up a message every time it needs to reconnect or hits an EOF.

Edited by Waldonnis
Link to comment
Share on other sites

  • 1 month later...
ddurdle

Is it normal that it appears that emby 3.5.2 has dropped the duration parameter when it makes the call for ffmpeg to do the recording?  This was a indicator in previous embys that it was a scheduled recording, and one could gauge from this duration parameter if the stream ended prematurely.  I noticed in emby 3.5.2, recording calls to ffmpeg no longer have a duration parameter.  Is that correct and intended?  

 

My recordings were rock solid reliable in older versions of emby because I could have ffmpeg take care to ensure if the stream cut out, to retry the stream and append to the existing recording.  I relied on the duration parameter.

 

I have a number of users testing DVR out for me in 3.5.2 and they report back some recordings that end prematurely, I assume because the stream cut out at some point.  I thought maybe emby had some new tricks to handle this in the newer version, so I didn't have to rely on my own methods. 

Link to comment
Share on other sites

The has nothing to do with it ending prematurely. Try using the stream looping feature to make it more resilient. Thanks.

Link to comment
Share on other sites

  • 2 weeks later...
ddurdle

Actually with some further testing yesterday, I wasn't utilizing the best method at capturing the q signal from emby to the ffmpeg process.  I revised the formula and now I can figure out if a stream recording needs to be kept alive during a failure vs proper ending of stream, without needing to know the -t duration.  

 

I'll continue to test, but I think the script will work on making my DVR recordings stable and complete  :D

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...