LiveTv Auto Loop Live Streams

[kjhedges 67]

So, Have the Emby server all set up, working great so decided to Subscribe for the few extra benefits.

 

So we move onto the LiveTV part.

 

I have working channels, (although the listings is in a mess at present) using m3u. The loop section is ticked as i believe is needed but the channel only plays for and records for average 30 seconds.

 

I have tried the same m3u in VLC and works ok with loop button enabled on VLC.

 

I have added the last embyserver log.

 

Any advise would be appreciated

embyserver.txt

[Luke 42077]

Hi, can you attach the ffmpeg log as well? Thanks.

[kjhedges 67]

I just open a channel, it played for about 30seconds then closed.

 

I have attached 2 ffmpeg that were created during process and latest embyserver

 

Thanks

ffmpeg-directstream-5a8bf1fa-fd64-4d32-8d34-1c53590baa15.txt

ffmpeg-transcode-165fd043-5785-4b07-bac8-ff615df8b861.txt

embyserver.txt

[Luke 42077]

In that directstream log the loop param was being applied. You're saying there was an issue there?

 

The transcode log is unrelated. That's from a video file.

[kjhedges 67]

Hi, yes.  The Directstream log was when played a channel which lasted for about 30 seconds

 

 

I was viewing the guide in livetv.  Clicked on a programme that was currently showing. Clicked Play and it played for about 30 seconds then just returned to the guide page.

[Luke 42077]

Can you try lowering the in-app quality setting to force a full transcode rather than remux? Try setting it to 1 mbps. I wonder if that will resolve it. Thanks.

[kjhedges 67]

Just change setting, ran again both for viewing and record. same thing.

ffmpeg-directstream-e492b90e-51c5-4ed1-9106-a4d759179f06.txt

record-transcode-7c532f1c-4e5f-450c-8604-1bb9b5900b5b.txt

[Luke 42077]

It looks like you didn't actually change the in-app quality setting. Where did you attempt to do that?

 

Let's just play for now, not record, Thanks.

[kjhedges 67]

When i play in the web app. there is a settings button within the play forward etc. I clicked the settings there and lowered to 480p - 1m

 

 

 

Edit:  Not sure if the atttached log is any more help

ffmpeg-transcode-0c512a56-b5a2-41de-a9ab-477710c890db.txt

Edited May 6, 2018 by kjhedges

[Luke 42077]

Ok yes that time the quality was applied. Unfortunately I'm not sure what's going on. The error in the ffmpeg log suggests that it doesn't like something about the source stream.

 

@@Waldonnis, what do you think? Thanks.

[kjhedges 67]

Ok thanks, in the meantime, i will try some other varied m3u's and post any differing results

[Luke 42077]

Great, thanks.

[Waldonnis 148]

Looks like ffmpeg's disconnecting at seemingly random points (probably not actually random), and the default behaviour of ffmpeg is to not try to reconnect when it hits what it thinks is an EOF or an error.  I tried the URL with ffplay and saw the same thing.  Adding reconnect options (reconnect_at_eof, reconnect_streamed, and reconnect_delay_max) with appropriate values allowed it to reconnect after a delay, but it was still getting interrupted semi-frequently and the playback wasn't really easy to follow/watch at times.

 

ffplay indicated that it reached an end of file at every point it choked, and I even saw some 403 and 404 errors when it tried to reconnect, so I'm guessing the provider has some latency issues in their encoding/writing process.  I would even guess that the EOFs aren't really EOFs, but rather malformed frames/packets that were the result of reading the upstream ts file faster than it was being written.  Not the first time I've seen this happen with live streams...

 

For reference, here's the ffplay line I used to check it (the same reconnect options are available in ffmpeg as well):

ffplay -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 2 <URL>

For grins, I tried -re without the reconnect options to see if slowing the streaming down to the input's framerate would help, but it didn't (figured it wouldn't, but it only took a few seconds to test so why not).  Oddly, I got a few 502 errors when I tried to do that, so there are probably web service issues as well that the upstream provider really needs to work out.  Even with the reconnect options, the output when testing encoding the stream was...not great.  Some audio choppiness and what I suspected to be a bit of video looping as well (hard to tell given what they were showing at the time), so I'm not sure if reconnecting is a true solution in this case.  I'll think about it in case there's another option that's just escaping me right now.

[Luke 42077]

Great, thanks for testing this out !

[kjhedges 67]

Hi,  Although I havent a real clue about all what waldonnis wrote above.   

 

 

I have since tried another few and the attached is a working remux with no problems that i saw viewing anyway.

 

 

ffmpeg-remux-a648895a-e483-459d-92d7-4e3df56b17ec.txt

[Luke 42077]

Thanks for the feedback.

[Anielarias 25]

was this ever fixed ?

[Luke 42077]

21 hours ago, Anielarias said:

was this ever fixed ?

   @Anielarias

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!