Seek to start failed, then drops out to the channel guide

[moshmont 8]

What causes "Seek to start failed" and "Operation not permitted" in the ffmpeg-directstream log file?  Quite often, while watching live TV, streaming will suddenly stop, and it drops back to the Channel Guide, and this is always what is in the log file.  I can always start it right back up with no problem.  When watching on something like TiviMate this doesn't happen, or at least not visibly.  Is there a setting that will make Emby recover from this rather than just drop out?

21:34:47.980 [segment @ 000002b4c31be740] Opening 'D:\Emby\transcoding-temp\5BA88A_320.ts.tmp' for writing
21:34:47.982 Seek to start failed.
21:34:47.982 http://localhost:34400/stream/db4f76cb29e3468da715236aec1f19ef: Operation not permitted
21:34:47.982 21:34:47.982 [segment @ 000002b4c31be740] Opening 'D:\Emby\transcoding-temp\5BA88A.m3u8.tmp' for writing
21:34:47.988 SegmentComplete=video:0 Index=320 Start=960.008700 End=960.258944 Duration=0.250244 offset_pts=0 start_pts=960008700 Frames=14 filename=hls/5BA88A/5BA88A_320.ts
21:34:47.988 frame=57557 fps= 61 q=-1.0 Lsize=  656050kB time=00:16:00.20 bitrate=5648.4kbits/s throttle=off speed=1.01x    
21:34:47.988 video:641047kB audio:15002kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
    Last message repeated 1 times
21:34:47.988 EXIT
 

Edited December 18, 2020 by moshmont

[moshmont 8]

Anybody out there? 

[Luke 42077]

Hi there, let's go over an example. Please attach the information requested in how to report a media playback issue. thanks !

[moshmont 8]

I'm not sure what more to add other than providing the entire log file, which I did below.  It's always just a matter of watching a channel on live tv.  I don't do anything at all, I'm just watching, at some point the stream stops and it drops into the tv guide.  I press select to start the channel back up and everything works fine until it happens again.  Emby server is on a Windows 10 system and I am watching from a 4K fire stick.  This has happened for as long as I have been using Emby, which I think has been since July of this year.

ffmpeg-directstream-951ed1f8-46eb-493e-8017-893113e74885_1.txt

[moshmont 8]

Sorry, I meant to include the server log from the same time.

embyserver-63743846400.txt

[Carlo 4561]

Hi, Anytime I've seen this happen it's a problem with a provider of m3u info or an Internet glitch where the latency builds and Emby runs out of data, or similar.

If you can provide the info as asked by Luke we can have a look.

[moshmont 8]

>> If you can provide the info as asked by Luke we can have a look.

I'll provide whatever else you think would help, but I'm not sure what more to provide.  Screen shots won't help.  That would just be a screenshot of the stream playing and then a screenshot of the channel guide.

It seems like what is happening is that, instead of buffering... the spinning circle and then finally resuming... it's just failing and dropping out of the stream.  I think I misspoke earlier when I said this has been happening since I started using Emby back in July.  It did used to buffer and recover.  But since quite a while ago, I never see the buffering. Instead it only suddenly drops out.

>> Anytime I've seen this happen it's a problem with a provider of m3u info or an Internet glitch where the latency builds and Emby runs out of data, or similar.

I agree that it is likely some disruption in the stream from the provider, but all other players seem to recover and resume streaming, from the same provider. Is there any setting that I might have inadvertently set that would cause the stream to die instead of trying to resume it?

[moshmont 8]

FYI: I've moved on to the beta version on the server and firestick.  I'll see if this is still a problem there.  

[Luke 42077]

Let us know how you get on. Thanks.

[moshmont 8]

So far I have not been having this happen with the beta server and client.       (Knock on wood)

[moshmont 8]

Unfortunately this has started up again.  I am using the betas of both the server and fire stick now.  This stopped for quite a while after I first loaded the betas.  The server version has not changed since, but new versions of the fire stick have been pushed out. (feel free to move this thread to the beta forum if that is possible).  Even though it is the beta version, the ffmpeg log file looks just like the one from the non-beta version that I posted above with the same seek to start error.  

[ebr 16170]

22 hours ago, moshmont said:

Unfortunately this has started up again.  I am using the betas of both the server and fire stick now.  This stopped for quite a while after I first loaded the betas.  The server version has not changed since, but new versions of the fire stick have been pushed out. (feel free to move this thread to the beta forum if that is possible).  Even though it is the beta version, the ffmpeg log file looks just like the one from the non-beta version that I posted above with the same seek to start error.  

Hi,  I think the switching of versions of things is likely coincidental and Cayars is correct that this is a problem at the source.

[moshmont 8]

I agree there is probably a problem at the source, but I would think it should at least give the spinning circle and then recover.  When I watch through other apps that is what happens.  

[Luke 42077]

Hi, we'll look at improving this. Thanks for the feedback.

[Ugnaughts 53]

@Luke

these  "seek to start failed " errors are most likely because of the provider. but the recording will start backup and finish. 

is emby capable of searching log context every minute or so to see if there is "seek to start failed " then restart recording?

and is this on the slate to be resolved anytime soon

 

[Luke 42077]

24 minutes ago, joekingcool said:

@Luke

these  "seek to start failed " errors are most likely because of the provider. but the recording will start backup and finish. 

is emby capable of searching log context every minute or so to see if there is "seek to start failed " then restart recording?

and is this on the slate to be resolved anytime soon

 

We do already detect when the ffmpeg process closes with an error and retry.

[Ugnaughts 53]

On 12/12/2023 at 10:44 PM, Luke said:

We do already detect when the ffmpeg process closes with an error and retry.

why on the "seek to start failed" it dont work?

i dose seem like its a problem with stream from provider when it happens. but if i restart as soon as failed then it works. 

right now i set recordings to -2 at begining +1 at the end. so it hopfully catches begining and end of show. and most important is to give ffmpeg a break for the channel. im assuming when shows are back to back and recordings have that buffer set. it records 2 streams from same channel for a bit. that might be to much for some providers. so far past 24 hrs has been good, knock on wood. 

maybe emby will restart recordings for  "seek to start failed" errors in a later release. 

for now i created an app that searches the log file contents every second. if it finds that error, it pulls the name of the show and sends me a text msg so i can restart it. but hopfully by changing the pre/post record time i wont have any more. 

 

 

[Ugnaughts 53]

i made an app that monitors for the "seek to start failed" error and restart recordings threw emby, in about minute. ive been vigorously testing and working with few other very talented ahk coders over past few days. ive tried a Varity of different show types and formats and all so far work. but i do have to say like anyone else. I'm not responsible for any damages type of lingo, use at your own risk, make backup of your timers.json, and test for your self.

you will have to make emby a service. i used nssm. if you don't want to run my app with admin rights, then there is another tool that changes the service to be run from local user. so you don't have to run my app as admin. ill post the script in ahk if you want to compile yourself, its very easy. or i will make an exe that's digitally signed by me and is trusted by antivirus. i do have paypal on my website if you would like to buy me a coffee, every little bit helps! ill put the log file below just showing how it has to cleanup syntax from file names to match data in the timers.json. before it updates the status of that particular recording. many thanks to users chunjee andymbody malcev at ahk forums for helping me put this together, mostly chunjee !!

ps: one way to get the "seek to fail" error is block ffmpeg with windows firewall. also all my other recordings emby does a great job at recovering from!

Edited December 21, 2023 by joekingcool