[solved] Emby DVR recordings cut short

[bry 12]

Good Morning,

 

I am testing some DVR options via Version 3.2.27.0.

 

Tuner: HDHR Prime

 

The dashboard shows that emby is actively recording but the file written is only 1MB.

 

Sanitized log attached. 

 

I tried to follow https://emby.media/community/index.php?/topic/739-how-to-report-a-problem/ best.

 

If there is anything else you would like please let me know.

 

Thank you,

 

bry

 

*edit1* - attempted a second recording and it worked. I'll continue to test every half hour. 

*edit2* - third recording stopped at 376k, the dashboard still shows that it is recording. and hdhr status shows that it is being used via emby. 

*edit3* - fourth recording failed as well - this one made it to 131mb

*edit4* - fifth recording failed. I am not seeing a log in the AppData\Roaming\Emby-Server\logs that is more recent than the original one I uploaded. 

Edited August 15, 2017 by bry

[Luke 42077]

Can you please attach the emby server log? thanks.

[bry 12]

luke, maybe I am confused at the steps this process takes. I just went back to check ~2 hours post the last recording and now everything is there in full. 

Edited August 15, 2017 by bry

[Luke 42077]

So the recordings  succeeded?

[Guest asrequested]

I remember instances in the past where recordings initially appear short, but after a library scan, they were shown to be complete. I never had this issue, but o remember reading a post like that. Possibly the same issue?

[bry 12]

So the recordings  succeeded?

 

They did - I am a bit confused though because in the past they have not, even as day(s) passed I did not go back and check. This time I was watching the actual recording path and the file sizes for 4/5 recordings did not go above a few megs. The second one happened to show the full file size. About 2 hours later I went back to check the recording path and the full size recordings were there. Does Emby store a temporary recording in a separate directory?

 

I remember instances in the past where recordings initially appear short, but after a library scan, they were shown to be complete. I never had this issue, but o remember reading a post like that. Possibly the same issue?

 

Maybe, I feel bad for making a thread and then the issue solving itself. I hate to waste Luke's time. Thanks for the reply Dofofus

[pir8radio 1312]

can you take a look at my log file?  search for "2018-10-08 18:59:59.514 " and you will see a recording timer set for WWE Monday night RAW (ffmpeg1.txt).    that recording went on for about 30 mins then just stopped short.   the show should have been from 7pm - 10pm   guide shows that same timeframe  I'll pm @@Luke the full log.

 

A second recording stopped after a only seconds of recording if you search for "Remy & Papoose  Meet The Mackies [New!]" in the log. (ffmpeg2.txt)

 

Here is a log snip, emby thinks all is good.    FFMPEG shows 404 error pulling the video but that's not the case as far as I can tell, I was watching the stream on another pc.

 

Im going to enable auto-loop and see if things get better.  But still curious of your opinion of the logs luke.

2018-10-08 19:30:45.146 Info App: FFMpeg recording exited with code 0 for E:\LiveTV Recordings\Series\WWE Monday Night RAW [New!]\Season 26\WWE Monday Night RAW [New!] S26E41.ts
2018-10-08 19:30:45.146 Info App: Recording completed to file E:\LiveTV Recordings\Series\WWE Monday Night RAW [New!]\Season 26\WWE Monday Night RAW [New!] S26E41.ts
2018-10-08 19:30:45.146 Info App: Recording completed: E:\LiveTV Recordings\Series\WWE Monday Night RAW [New!]\Season 26\WWE Monday Night RAW [New!] S26E41.ts
2018-10-08 19:30:45.146 Info MediaSourceManager: Live stream 74c5f8260110fe55429c1c6157bd1ae3 consumer count is now 0
2018-10-08 19:30:45.146 Info MediaSourceManager: Closing live stream a17c75760a04e99b68cf766e11316e1c_09efa0d56b934a82adec00a87b837fb0_74c5f8260110fe55429c1c6157bd1ae3
2018-10-08 19:30:45.146 Info App: Closing SharedHttpStream
2018-10-08 19:30:45.146 Info MediaSourceManager: Live stream a17c75760a04e99b68cf766e11316e1c_09efa0d56b934a82adec00a87b837fb0_74c5f8260110fe55429c1c6157bd1ae3 closed successfully
2018-10-08 19:30:45.146 Info App: Triggering refresh on E:\LiveTV Recordings\Series\WWE Monday Night RAW [New!]\Season 26\WWE Monday Night RAW [New!] S26E41.ts
2018-10-08 19:30:45.147 Info App: Refreshing recording parent E:\LiveTV Recordings\Series\WWE Monday Night RAW [New!]\Season 26
2018-10-08 19:30:45.271 Debug MediaEncoder: Ffprobe -i file:"E:\LiveTV Recordings\Series\WWE Monday Night RAW [New!]\Season 26\WWE Monday Night RAW [New!] S26E41.ts" -threads 0 -v info -print_format json -show_streams -show_chapters -show_format
2018-10-08 19:30:45.271 Info MediaEncoder: ProcessRun 'ffprobe' Execute: C:\Users\User\AppData\Roaming\Emby-Server\System\ffprobe.exe -i file:"E:\LiveTV Recordings\Series\WWE Monday Night RAW [New!]\Season 26\WWE Monday Night RAW [New!] S26E41.ts" -threads 0 -v info -print_format json -show_streams -show_chapters -show_format
2018-10-08 19:30:45.280 Info MediaEncoder: ProcessRun 'ffprobe' Started.

Edited October 9, 2018 by pir8radio

[Luke 42077]

The ffmpeg log has 404 not found errors at the bottom. I am not sure what's going on there. It's almost as if the url went bad during the broadcast.

[pir8radio 1312]

The ffmpeg log has 404 not found errors at the bottom. I am not sure what's going on there. It's almost as if the url went bad during the broadcast.

 

Yea i think it has to do with how they do their security...       Another quick question, what does emby handle better  .ts or .m3u8?    So far most of the issues ive had were with .m3u8   I'm testing .ts streams now.    should be about the same but didnt know if emby handles them differently. 

[Luke 42077]

.ts is simpler.